合并代碼用 merge 還是用 rebase ? 兩者的區(qū)別是什么？
共 2733字，需瀏覽 6分鐘
·
2024-07-16 09:03
回復(fù)架構(gòu)師獲取資源
大家好，我是你們的朋友架構(gòu)君，一個會寫代碼吟詩的架構(gòu)師。
1）git rebase 讓你的提交記錄更加清晰可讀
git rebase 的使用
rebase 翻譯為變基，他的作用和 merge 很相似，用于把一個分支的修改合并到當(dāng)前分支上。
如下圖所示，下圖介紹了經(jīng)過 rebase 前后提交歷史的變化情況。
現(xiàn)在我們來用一個例子來解釋一下上面的過程。
假設(shè)我們現(xiàn)在有2條分支，一個為 master ，一個為 feature/1，他們都基于初始的一個提交add readme進(jìn)行檢出分支，之后，master分支增加了3.js和4.js的文件，分別進(jìn)行了2次提交，feature/1也增加了1.js和2.js的文件，分別對應(yīng)以下2條提交記錄。
master 分支如下圖：
feature/1分支如下圖：
結(jié)合起來看是這樣的
此時，切換到 feature/1 分支下，執(zhí)行 git rebase master ，成功之后，通過 log 查看記錄。
如下圖所示：可以看到先是逐個應(yīng)用了 mater 分支的更改，然后以 master 分支最后的提交作為基點，再逐個應(yīng)用 feature/1的每個更改。
所以，我們的提交記錄就會非常清晰，沒有分叉，上面演示的是比較順利的情況，但是大部分情況下，rebase 的過程中會產(chǎn)生沖突的，此時，就需要手動解決沖突，然后使用git add 、git rebase --continue的方式來處理沖突，完成 rebase，如果不想要某次 rebase 的結(jié)果，那么需要使用 git rebase --skip來跳過這次 rebase。
2）git merge 和 git rebase 的區(qū)別
不同于 git rebase的是，git merge 在不是 fast-forward（快速合并）的情況下，會產(chǎn)生一條額外的合并記錄，類似Merge branch 'xxx' into 'xxx'的一條提交信息。
另外，在解決沖突的時候，用 merge 只需要解決一次沖突即可，簡單粗暴，而用 rebase 的時候 ，需要一次又一次的解決沖突。
3）git rebase 交互模式
在開發(fā)中，常會遇到在一個分支上產(chǎn)生了很多的無效的提交，這種情況下使用 rebase 的交互式模式可以把已經(jīng)發(fā)生的多次提交壓縮成一次提交，得到了一個干凈的提交歷史，例如某個分支的提交歷史情況如下：
進(jìn)入交互式模式的方式是執(zhí)行：
git rebase -i <base-commit>
參數(shù)base-commit就是指明操作的基點提交對象，基于這個基點進(jìn)行 rebase 的操作，對于上述提交歷史的例子，我們要把最后的一個提交對象（ac18084）之前的提交壓縮成一次提交，我們需要執(zhí)行的命令格式是：
git rebase -i ac18084
此時會進(jìn)入一個 vim 的交互式頁面，編輯器列出的信息像下列這樣。
想要合并這一堆更改，我們要使用 squash 策略進(jìn)行合并，即把當(dāng)前的 commit 和它的上一個 commit 內(nèi)容進(jìn)行合并， 大概可以表示為下面這樣。
pick ... ...
s ... ...
s ... ...
s ... ...
修改文件后 按下:然后wq保存退出，此時又會彈出一個編輯頁面，這個頁面是用來編輯提交的信息，修改為feat: 更正，最后保存一下，接著使用git branch查看提交的 commit 信息，rebase 后的提交記錄如下圖所示，是不是清爽了很多？rebase 操作可以讓我們的提交歷史變得更加清晰。
特別注意，只能在自己使用的 feature 分支上進(jìn)行 rebase 操作，不允許在集成分支上進(jìn)行 rebase，因為這種操作會修改集成分支的歷史記錄。
來源：https://blog.csdn.net/qq_24147051
這些年小編給你分享過的干貨
2.優(yōu)質(zhì)ERP系統(tǒng)帶進(jìn)銷存財務(wù)生產(chǎn)功能（附源碼）
3.優(yōu)質(zhì)SpringBoot帶工作流管理項目（附源碼）
5.SBoot+Vue外賣系統(tǒng)前后端都有（附源碼）
轉(zhuǎn)發(fā)在看就是最大的支持??