What do git-rebase and git-merge do? What's the difference?

What do git-rebase and git-merge do? What is the difference between git-rebase and git-merge? The following article will introduce to you the difference between git-rebase and git-merge. I hope it will be helpful to you!

Using Git for version control should be one of the workflows that most engineers encounter every day, but what I use is nothing more than push, pull, merge, checkout or log and other instructions. If you go more in-depth, you won’t know anything about it. During the interview was asked this question: "Do you know the difference between Git's merge and rebase?"

I was immediately confused after listening to it. To me, rebase is a tool used to organize commits, and it actually works. Compare with merge? [Recommended study: "Git Tutorial"]

git-rebase

Let me first talk about what I usually use the rebase command for. , if I add a new unit test and then commit, then log will have an additional record of commit:

But after committing, I discovered that I had missed writing another test case, so after making up for it, I committed again:

At this time, there will be another commit in the record, but for me, these two commit are actually doing the same thing, so before pushing to remote, You will want to sort out the commits first and merge the two records.

There are two ways to merge these two records. The first is to reset before adding the first test case, and then do it directly commit . The second method is to use rebase to handle it!

First let us take a look at the current log:

My purpose is to combine 9dc67ff and 87af945 Organized into one, so the commits to be adjusted are from init, that is, all the commits after the commit id is 7eb57cb. If combined with the rebase command, it will be:

git rebase -i 7eb57cb

After typing, you will jump to the vim editing screen:

You will see all the commits after 7eb57cb (currently only 9dc67ff and 87af945), then change the pick of 9dc67ff to squash, which means merging it with the previous commit . Click i first and then start editing the content with vim:

After editing, you can click esc and enter :wq to save, if you are just curious, come in Play and have a look. If you don’t want to save, just enter :q!. After completing the above process, check the log again and you will find that the two commits have become one. After saving, you will jump to the commit message screen. Here you can enter the merged commit message, but I will not change it and save it directly:

End above After the process, check the log again, and you will find that two commits have become one:

Nice first, the above operation is the interactive mode of rebase, in git rebase The -i entered later is actually the abbreviation of interactive.

git-merge

Everyone should be very familiar with the merge command, because when doing new features, you usually pull out a branch and then merge Return to the main branch such as master or develop. The operation process is as follows:

在 merge 的时候会有两种情况，第一种是  fast-forward，会把被合并分支的 HEAD 的 reference 移到要合併分支内最新的 commit 上，上方操作的 merge 结果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，画成图的话就是这样子：

但是如果在执行 merge 的时候产生冲突，那分支的合并行为就会和 fast-forward 有点不同了。举例来说，我分别在 master 和 string-library 的同一个文件添加内容，那当我执行 merge 的时候就会要求先修复冲突：

修复完后，再执行 commit 完成合并，而这一次合并时，会再多一个 commit 是有关 merge 了 string-library 分支的纪录：

这个情况画成图就会像这样子：

git-rebase 与 git-merge 的差异

看完上方对 rebase 和 merge 的介绍后，你也许会想说：

「咦？那这两个不是完全不同的东西吗？」

对的，原本我也是这麽认为，一直到我去看了 git-rebase 的文档，才发现原来我一直误会它了。在 git book 的 rebase 篇章，第一段就说明了，在 Git 里有两种方法可以用来整合两个分支，而这两个在上方都有提到，分别为 merge 和 rebase：

从上方的 merge 例子已经知道了，merge 在合并的时候会有 fast-forward，和冲突时用一个 commit 记录合并变更的两种情形。而 rebase 的整合方式非常有趣，依照关于 rebase 的另一段说明，它可以「把某个分支中所有 commit 的过程，以另一个分支的 commit 为基础重播一遍」：

这是什麽意思呢？首先让我们回到上述的例子，并在 master 分支上用 reset，让 master 的版本回到合并 string-library 之前：

现在我们要用 rebase 指令，将 string-library 所有的 commit 修改，以 master 的 commit 为基础跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：

git checkout string-library

然后再输入 git rebase 指令，并于后方指定要在哪个分支上重播：

git rebase master

执行结果：

在 rebase 重播 commit 的过程中，和 merge 相似的地方在于，如果有冲突的话还是需要解决，但在解决后，并不是使用 commit 指令进行合并，而是要输入 git rebase --continue，让 rebase 可以继续重播接下来的 commit：

重播完成时，会显示目前重播到哪个 commit，以 string-library 来说就是最新的add string unit test D。这时候的分支关系，画成图就会变成：

上图在经过 rebase 之后，string-library 里 07e38fb 修改，会以 master 的 commit 为基底再重播一次。

需要注意的是，重播后的 commit id 会和原本的不一样，这等于完全改写了分支内所有的 commit 历史纪录。

In addition, after executing the rebase, string-library has not actually been merged back to the master branch, so it is still necessary to switch back to the master and execute merge to complete the merge:

Because rebase has been used to handle the commit conflicts during replay, now the merge will go directly to the fast-forward merge, and there will not be another commit record for the merge.

Advantages and disadvantages of using git-rebase to merge

Advantages

• No redundant commits will be generated during the merge.

• Conflicts can be handled in commit units during replay.

• When merging, it will be arranged according to the commit of the branch, so that the review issue or feature processing process can be clearly understood. If you use merge, the commits of the two branches will be arranged in chronological order after the merge.

• When contributing to an open source project, if you rebase before pushing, the author can directly merge in a fast-forward manner without the need to resolve conflicts separately.

Disadvantages

The biggest disadvantage is the one mentioned above. Using rebase will modify the history of commits. If you organize commits or branches locally, that's fine. , but if you accidentally change the remote branch, and then accidentally use git push -f, you may be hated by your colleagues, or you may be submitted to a purely northern engineer.

Should I use git-rebase or git-merge?

After checking some information, I found that both rebase and merge have their own supporters. I will first explain their ideas and then subjectively mention my own opinions.

git-merge Pai

Supportgit-merge Pai’s engineers believe that the value of version records lies in project commits. That is, "what actually happened in the history of this project". If you modify these historical records, it will be very bad. So even though the contents of different branches are mixed together after the merge, they still illustrate the history of the project.

git-rebase sent

supportgit-rebase The engineers sent felt that commit was talking about the "evolution process" of the project. What happened is important. Even if the commit history is modified, what happened remains unchanged. Since you can use a clearer and more concise record for future generations to read, you should do so.

Personal subjective opinion

I personally still use git-rebase to modify commits to make the history records simpler and easier to read, but the use is limited to push to remote Previously, if I had pushed the records to remote today, I would not modify them no matter how messy they were. After all, the remote records were shared by everyone. If I did not modify them at will, I would respect other members of the team.

[Related video tutorial recommendations: web front-end]

The above is the detailed content of What do git-rebase and git-merge do? What's the difference?. For more information, please follow other related articles on the PHP Chinese website!