Part III: What is rebase?

Content Summary

• The first part: What is a commit hash?
• Part II: What is merge?
• Part III: What is rebase?

In the first part, we discuss what a commit hash is, and one of the most important features is that commit cannot be modified. The hash value is generated from the information stored in the commit, so if you modify a commit or commit hash, you must create a new commit. We also discussed the hash value of each commit that stored its previous commit. What we're not talking about is its impact on our git history.

In fact, commit hashes are generated based on the information they store, which contains the hash value of the previous commit, so it is virtually impossible to modify your commit history. Each commit is like a link on a chain, tightly connected to the previous link.

If you have the same metal chain, it is impossible to connect the front and the back ring without interrupting them. However, this will be worse in a git environment. This analogy is not reliable here, because on a metal chain you can weld a new ring to reconnect the front and back loops. But in git, you can't do that.

If you want to delete a commit in the middle of commit history, then a commit will point to a non-existent commit hash. Because you can't change the commit without changing the hash, you can't simply generate a new commit to reference the previous commit, and then a commit still references the most primitive commit hash.

If you change a property of a commit, the resulting hash value will not be the same, and the latter commit will not refer to the new commit. The result is that you have to modify the latter commit to refer to the new commit hash, which will also cause a change in the commit hash, so go all the way down to the end of the chain.

It was Rebase's turn to play. If you remember the second part, when we merge the feature1 branch into the master branch, there is a diagram showing the relationship between the commits.

The merge works well, but with all the fork and cross-cross commit relationships, the Git repository's graphics quickly get out of control. It's just a small snippet of a git repository I work on.

If you use a git GUI software, chances are you've seen something like that. Merge is the simplest way to move the difference between branches, because it avoids breaking the commit history and causing the egg pain. However, once you have a more profound understanding of how rebase works, you will benefit from it. For a chestnut, if we rebase branch to branch in the demo repository feature1 master (translator Note: This means switching to feature1 branches, executing git rebase master commands), will get a very beautiful clean history,

Did you notice? Now the history is a straight line. How does git do that? If you remember, our Commit 3 and Commit 4 is shared Commit 2 as its common parent node, Commit 3 referenced Commit 2 as its previous commit. Now you may wonder why it looks Commit 3 like it will be the Commit 4 last commit.

Remember what I just said, if you want to break the chain from the middle, you have to recreate the commit after creating it from this point until the end. Yes, this is actually what rebase did.

If you look closely, you will find that Commit 3 Commit 5 Commit 6 The commit hash has all changed. These 3 commits are submitted on the feature 1 branch. feature 1git rewrites all commits until the end by manipulating the branch rebase to the master branch, starting with the master first commit that the branch forked out feature 1 . It stores the difference between each commit in a temporary file, and then begins rewriting our branch history. And this time, the branch is from the master Commit 4 beginning.

Git creates a new commit for each commit on the branch and, of course, changes the commit hash value. When it creates a new commit, the first commit is changed to refer to the master newest commit () of the branch instead of the Commit 4 original ( Commit 2 ). This re-submission of your changes as a new commit process is called "your commits on the master branch replay".

Note: Do not confuse terminology. Rebase to the branch master does not modify the master branch itself, it means that your branch commits will follow master the newest commits on the branch (translator Note: This 你的分支 is the point feature 1 ).

You will notice that the master branch is still pointing Commit 4 , and its commit hash value is unchanged. If we now switch to the master branch and then feature 1 merge the branches into the master branch, this will not result in a merge commit. This is just a fast forward commit, meaning that git will simply master move the pointer to the branch straight to the point feature 1 where the branch is pointing.

If we don't feature 1 merge branches into master branches, we have more to do, more commits to commit, and we may fork a warehouse again. The commit of our next master branch will point to Commit 4 its parent node, and the feature 1 first commit of the branch is also pointed to Commit 4 as its parent. In order to get a straight commit history, we need to switch to the branch again and feature1 then rebase to the master branch again. This happens very often, such as when you submit a pull request on GitHub and it expires. If the maintainer of the project does not merge your pull request, but continues to do some other work on the project, then your pull request needs another rebase operation to get a clean git history. Rebase your work to the original warehouse branch allows the pull request to take a simple fast-forward approach when merging. Accepting a pull request is just a simple merge. If you rebase your work before submitting the pull request, the merge is a fast-forward merge, which also ensures that the original warehouse is clean. (Translator Note: This 干净 refers to the absence of additional merge information.) ）

Dangerous!!!

This part of the content is the use of rebase some warnings, mainly in collaboration with a number of people need attention. Because Rebase is a rewrite commit operation, it is relatively dangerous, the author gives the opinion is:

Undoing a rebase is isn't easy, and often impossible so you really need to pay attention to what you ' re doing. The benefits of rebasing is great, but isn't if you don ' t know "what do you ' re doing.

Undoing a rebase operation is not easy, and is often impossible. You must be very careful what you are doing. Rebase benefits, if you do not know what you are doing, do not use REABSE.

This part of the content is not translated, you are interested in reading the original.

English Address: http://codetunnel.com/merge-vs-rebase-part-3-what-is-a-rebase/

Part III: What is rebase?