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 移到要合併分支內(nèi)最新的 commit 上，上方操作的 merge 結(jié)果就是 fast-forward，master 的 HEAD 被移到 string-library 的最新 commit，畫成圖的話就是這樣子：

但是如果在執(zhí)行 merge 的時候產(chǎn)生沖突，那分支的合并行為就會和 fast-forward 有點不同了。舉例來說，我分別在 master 和 string-library 的同一個文件添加內(nèi)容，那當(dāng)我執(zhí)行 merge 的時候就會要求先修復(fù)沖突：

修復(fù)完后，再執(zhí)行 commit 完成合并，而這一次合并時，會再多一個 commit 是有關(guān) merge 了 string-library 分支的紀(jì)錄：

這個情況畫成圖就會像這樣子：

git-rebase 與 git-merge 的差異

看完上方對 rebase 和 merge 的介紹后，你也許會想說：

「咦？那這兩個不是完全不同的東西嗎？」

對的，原本我也是這麼認(rèn)為，一直到我去看了 git-rebase 的文檔，才發(fā)現(xiàn)原來我一直誤會它了。在 git book 的 rebase 篇章，第一段就說明了，在 Git 里有兩種方法可以用來整合兩個分支，而這兩個在上方都有提到，分別為 merge 和 rebase：

從上方的 merge 例子已經(jīng)知道了，merge 在合并的時候會有 fast-forward，和沖突時用一個 commit 記錄合并變更的兩種情形。而 rebase 的整合方式非常有趣，依照關(guān)于 rebase 的另一段說明，它可以「把某個分支中所有 commit 的過程，以另一個分支的 commit 為基礎(chǔ)重播一遍」：

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

現(xiàn)在我們要用 rebase 指令，將 string-library 所有的 commit 修改，以 master 的 commit 為基礎(chǔ)跑一次。使用 rebase 合并的第一步，要先切到想重播 commit 的分支：

git?checkout?string-library

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

git?rebase?master

執(zhí)行結(jié)果：

在 rebase 重播 commit 的過程中，和 merge 相似的地方在于，如果有沖突的話還是需要解決，但在解決后，并不是使用 commit 指令進(jìn)行合并，而是要輸入 git rebase --continue，讓 rebase 可以繼續(xù)重播接下來的 commit：

重播完成時，會顯示目前重播到哪個 commit，以 string-library 來說就是最新的add string unit test D。這時候的分支關(guān)系，畫成圖就會變成：

上圖在經(jīng)過 rebase 之后，string-library 里 07e38fb 修改，會以 master 的 commit 為基底再重播一次。

需要注意的是，重播后的 commit id 會和原本的不一樣，這等于完全改寫了分支內(nèi)所有的 commit 歷史紀(jì)錄。

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!