A Guide to Git Interactive Rebase, with Practical Examples

Git interactive base change: a powerful tool to improve development efficiency

Git version control has become standard in the toolbox of modern developers. Commands such as commit, push and pull have long become muscle memory. However, relatively speaking, few developers understand the "more advanced" features in Git and the huge value of these features! This article will explore one of the most powerful tools in Git - "Interactive Rebase".

Core Points

• Interactive Rebase is a powerful Git tool that allows developers to create well-structured commit history, making the code base of projects easier to read and understand.
• Interactive rebase can be used to edit old commit information, delete commits, merge multiple commits, reorder commits, repair old commits, and split/reopen old commits for editing.
• It is important not to use interactive rebase on commits that have been shared with colleagues in the remote repository, as it will rewrite history. Instead, you should use it to clean up local commits before merging them into the team branch.
The basic mechanisms of interactive base operations include identifying the submission history part to be operated, starting the session with the
• command, and then specifying the required action in the open editor window. git rebase -i
Interactive rebase can be used to edit old commit information, delete unnecessary commits, and merge multiple commits into one, thereby optimizing and cleaning up the commit history.

Why interactive rebase should be part of every developer toolbox

In short, it is no exaggeration to say that interactive rebase can help you become a better developer by allowing you to create a clean and well-structured commit history in your project.

Why is a well-structured submission history important? Imagine the opposite: a difficult-to-read submission history, you don't know what your colleague's recent changes actually did. There will be more and more "dark corners" in projects like this, and you only know the small part of your participation.

Compare it with a clean and well-structured commit history: it helps make the project's code base more readable and and

easier to understand. This is a necessary part of a healthy, lasting program!

What can interactive base change do for you Interactive rebase helps you optimize and clean up your commit history. It covers many different use cases, some of which allow you to do the following:

• Edit old submission information
• Delete the submission
• Merge/combine multiple commits
• Reorder Submission
• Fix old commit
• Split/reopen old commit for editing

When to use interactive rebase (and when not!)

Like some other Git tools, interactively re-base "rewrite history". This means that when you use interactive rebase operations to operate a series of commits, this part of the commit history will be rewritten by : the commit's SHA-1 hash will change. They are brand new commit objects, so to say. The fact that

requires a simple but important rule to be followed: Don't use interactive rebases (or other tools to rewrite history) on commits you have shared with colleagues in the remote repository. Instead, use it to clean up your own local commits—for example, in one of your own feature branches—and then merge them into the team branch.

Basic mechanism of interactive base operation

Although interactive rebases can be used for many different things, their basic workflow is always the same. Once you have a firm understanding of this basic mechanism, interactive rebase loses its “complex and mysterious” atmosphere and becomes a valuable and easy-to-use tool in your toolbox.

Step 1: Where should you start the session?

The first question you need to answer is: "Which part of the commit history do I want to operate?" This tells you where to start an interactive rebase session. Let's give a practical example, suppose we want to edit the old commit information (this is exactly what we're going to do later in practice).

Our starting situation is shown in the figure below, we edit the old submission information through interactive change basis.

In order to be able to change the commit information in C2, we must start the interactive rebase session at its parent commit (or earlier, if you prefer). In this example, we will use C1 as the starting point for the interactive rebase session.

Step 2: Start the actual session!

Starting an actual session is very simple:

We use the

command with the

<code>$ git rebase -i HEAD~3</code>

flag (indicates that we really want it to be "interactive") and provide the basic commit (which we came up with in the first step above). In this example, I used

to specify a commit that "lagged behind HEAD commits 3 commits". Alternatively, I could also provide a specific SHA-1 hash. -i git rebaseStep 3: Tell Git what you want to doHEAD~3

After starting the interactive rebase session, you will see an editor window where Git lists a series of commits—from the latest commit all the way to (but not included) the basic commit you selected in step 1 as the basic commit Submission.

In this step, two points need to be paid attention to:

1. Submissions are listed in reverse order! We expect the latest submissions that appear at the top of will appear at the bottom of of the list. Don't worry: your Git repository is intact! ? Remember that we are performing an interactive change base operation, which requires Git to reapply commits from old to new at the end of the operation. Don't make actual changes in this editor window! While you might be tempted to change the commit information directly in this editor window (after all, that's exactly what we want to do...), you have to be patient. Here we are just telling Git what we want to do - rather than make the actual changes. I will demonstrate this in practice soon!
2. With this theoretical overview, let's dive into some practical cases together!
Edit old submission information

One of the most popular use cases for interactive rebase is that you can edit old submissions afterwards. You may know that

also allows you to change the information submitted - but this only applies to the latest

submissions. For any commit older than this, we have to use interactive rebase!

Let's look at a specific scenario. Below is an image of the error submission information that needs to be corrected. git commit --amend

Note: For a better overview and clearer visualization, I used the Tower Git desktop client in some screenshots. You don't need a Tower to follow this tutorial.

For our example, suppose we want to edit the message for the current submission titled "Optimize markup structure in index...".

Our first step is to determine the basic commit of this interactive rebase session. Since we have to (at least) return to the parent commit of our "bad apple" commit, we use (three commits behind HEAD commits, i.e. the commit titled "Change headlines...") as the starting point for the session:

After executing this command, your favorite editor will open and display the list of commits you just selected (by providing a basic commit).

HEAD~3

<code>$ git rebase -i HEAD~3</code>

A reminder: While you may be tempted to do this, we will not change the submission information here. We only use the "operation keyword"

to mark the corresponding rows of

. In our case, we want to override the commit (which means we want to change the commit information, but keep the rest of the commit).

In fact, all available action keywords are specified at the bottom of this window - so there is no need to remember anything!

Once you replace the standard keyword with your preferred action keyword (which means "accept commits as is"), you simply save and close the window.

After doing this, a new editor window will open with the current commit information. Finally, we can do what we planned to do in the beginning: edit this old commit message!

After we make changes and save and close the editor window, the interactive rebase session is complete—our submission information has been updated! ?

Delete unwanted submissions

Interactive rebase also allows you to delete old commits from history that you don't need (or don't want). Imagine you accidentally include a personal password in your recent submission: In most cases, such sensitive information should not be included in the code base.

Also remember that simply deleting the information and committing it again doesn't really solve your problem: it means that the password is still saved in the repository as an old commit. What you really want is to delete

this data completely cleanly from the repository! Let us first determine the basic commit of the interactive rebase session. Since we need to start at least with the parent commit of the wrong commit, we use the "Optimize markup structure..." commit as our basis:

Please note that this time I used the specific SHA-1 hash in the

<code>$ git rebase -i HEAD~3</code>

command. Of course, in addition to commit hash, I can also use

to handle that commit. git rebase -i HEAD~2After executing this command, we will see a commit list again.

This time, we use the

action keyword to get rid of unwanted commits. Or, in this special case, we can simply delete the entire line from the editor. If a row no longer exists when saving and closing the window (represents a commit), Git will delete the corresponding commit.

dropWhatever you choose, after saving and closing the editor window, the submission will be deleted from your repository history!

Merge multiple commits into one

Another use case for interactive rebase is when you want to merge multiple separate commits

into one. Before we dive into how to work, let's spend a few minutes discussing when or why it can be valuable.

Generally speaking, making a commit "larger" (by combining multiple commits into one) is not a good strategy in most cases. The general rule of thumb is to keep the commit as small as possible, as "smaller" means "easier to read and understand". However, in some cases, this still makes sense. Here are two examples:

• Imagine that you noticed something wrong with the old commit. You can then proceed to generate a new commit to fix the issue. In this case, it makes sense to merge these commits into one: After all, newer commits are just a "stoppable" to fix problems that shouldn't have existed. By combining these commits, it seems like there is no problem at all!
• Another example is when you notice that you are doing a little bit too detailed. Making small commits is good, but filling your commit history with many unnecessary small commits will mean exceeding the target.
The basic principles in both examples are the same: by combining two (or more) commits that would have been a commit, you are creating a cleaner, more readable commit history!

Let's complete a practical example together and use the situation shown in the following picture as our starting situation.

Suppose that semantically it makes more sense to merge these two commits into one commit. Using the interactive rebase tool, we can do this:

squash So far, you've gotten used to what's going on: An editor window will open with a list of submissions.

<code>$ git rebase -i HEAD~3</code>

I have mentioned that in this case we will use the operation keyword. There is one important thing to know about how

works:

The lines you marked with keywords will merge with the lines directly above! squash This explains why I marked line 2 with the squash keyword in our example. After saving and closing this window, a new window will open. This is because, by combining multiple commits, we will of course create a new commit. And this submission also requires submission information, just like any other submission! squash

What you see in the screenshot above is what Git has prepared for us: it combines the submission information of the corresponding original commit with some comments. Feel free to delete old messages and start over—or keep them and add more information.

After saving and closing this editor window, we can proudly say: it used to be two separate commits, but now it is one commit!

Use the powerful functions of interactive base change

I hope you agree that Git's interactive rebase tool is very valuable! As developers, we must strive for a clean and clear commit history. This is a key factor in keeping the code base healthy and easy to understand (for your teammates and yourself, after a while has passed).

If you want to know more, I highly recommend the "Git First Aid Kit". This is a (free) short video collection that shows you how to clean up and undo errors in Git.

Have fun!

Git Interactive Change Base FAQ (FAQ)

What is the difference between Git rebase and Git merge?

Git rebase and Git merge are two different ways to integrate changes from one branch into another. Git merge is a way to directly combine code from two different branches. It creates a new commit in the history, preserving the chronological order of the commits. Git rebase, on the other hand, is a way to move or combine a series of commits into a new basic commit. It's like saying "I want to add other people's work on my changes". In other words, it allows you to place changes to the current branch on the top of another branch.

How to undo Git rebase?

If you want to undo the Git rebase, you can use the command git reflog to find the commit you want to return to, and then use the command git reset --hard HEAD@{number}. The git reflog command displays a list of each change made to the HEAD, and the git reset command allows you to set the current HEAD to the specified state.

What is the purpose of Git interactive rebase?

Git interactive rebase allows you to change commits in a variety of ways, such as editing, deleting, and compression. You can not only change the commit information, but also change the actual code (if you make a mistake). This is a powerful tool that gives you complete control over the submission history of your project.

How to use Git interactive variable-base compression submission?

Compression is the act of merging multiple commits into one commit. In Git, you can compress the commit using the git rebase -i command followed by the commit hash to compress. In the open text editor, you can mark the commit you want to compress by replacing pick with squash or s.

What are the risks of using Git interactive rebase?

While Git interactive rebase is a powerful tool, it can be dangerous if used improperly. It rewrites the commit history, which can cause problems if you are dealing with a public branch that others are also dealing with. It is recommended to use it on local branches that have not been pushed yet.

How to resolve conflicts during Git change base?

Clashes may occur during the process of rebase. Git will pause and allow you to resolve these conflicts before continuing. You can fix conflicting changes by editing files and then use git add to add resolved files to resolve conflicts. After all conflicts are resolved, you can continue to change the base using git rebase --continue.

Can I use Git interactive change base to split the commit?

Yes, you can split a commit into smaller commits using Git interactive rebase. This is very useful if you make multiple changes in one commit but then decide that they should be separate commits.

How to edit submission information using Git interactive change basis?

You can edit submission information during interactive rebase. In the submission list, replace pick with reword or r to mark the submission to be edited. When continuing, Git will open a text editor for each submission marked reword, allowing you to change the submission information.

What is the difference between Git rebase and Git pull?

Git pull is a command that takes changes from a remote repository and merges them into the current branch. On the other hand, Git rebase is a command that moves or combines a series of commits into a new basic commit. While both commands are used for integration changes, they are performed differently.

Can I use Git interactive rebase to change the order of commits?

Yes, you can use Git interactive rebase to change the order of commits. In the commit list, you can simply change the order of rows to change the order of commits. This is very useful if you want to make your commit history more logical or clearer.

The above is the detailed content of A Guide to Git Interactive Rebase, with Practical Examples. For more information, please follow other related articles on the PHP Chinese website!