本章主要測(cè)試講解
-
git merge和git rebase指令的用法和進(jìn)行分支合并，并做簡(jiǎn)單比較分析。
測(cè)試過(guò)程內(nèi)容較多，每個(gè)步驟都逐一截圖以便真實(shí)說(shuō)明，也有列示用法。若不感興趣，可直接查看總結(jié)部分。
測(cè)試過(guò)程
前置說(shuō)明
關(guān)于無(wú)論是使用 merge 還是 rebase 進(jìn)行合并，出現(xiàn)沖突的原因都是在不同的分支修改了同一處的代碼，合并時(shí)版控工具 git 不知道保留哪一份的修改，從而導(dǎo)致沖突，需要合并人員去判斷并解決。
使用 merge 和 rebase 合并的做法
大概流程：
測(cè)試 git merge 和 git rebase 的合并及解決沖突效果：
- 1 準(zhǔn)備測(cè)試項(xiàng)目及分支記錄
- 創(chuàng)建 master、dev1、dev2 三個(gè)分支
- 除了 master 創(chuàng)建 dev1 和 dev2 的初始提交外，3 個(gè)分支各自有兩個(gè)不同的提交記錄
- 時(shí)間順序?yàn)椋?br>
master 新建空文件，再初始提交 –>
創(chuàng)建 dev2 –> dev2 commit 第一次文件修改 –> dev2 commit 第二次文件修改 –>
切回 master 創(chuàng)建 dev1 –> dev1 commit 第一次文件修改 –> dev1 commit 第二次文件修改 –>
切回 master –> master commit 第一次文件修改 –> master commit 第二次文件修改 –>
進(jìn)行使用 git merge/git merge 合并測(cè)試……
- 時(shí)間順序?yàn)椋?br>
master 新建空文件，再初始提交 –>
- 2 使用 git merge 進(jìn)行合并
- 3 使用 git rebase 進(jìn)行合并
- 4 對(duì)比兩者合并的歷史記錄，分析優(yōu)缺點(diǎn)和使用場(chǎng)景
測(cè)試步驟
準(zhǔn)備測(cè)試項(xiàng)目及分支記錄
相關(guān)命令請(qǐng)看截圖
準(zhǔn)備測(cè)試項(xiàng)目 test-conflict，新建一個(gè) test1.txt 文件（后續(xù)新建的文件，最好都改成 UTF-8，windows 下默認(rèn)是 ANSI，操作可能會(huì)產(chǎn)生亂碼），內(nèi)容為空，并 master 分支初始提交。
以 master 分支創(chuàng)建 dev2 分支
dev2 以 master 分支為基準(zhǔn)，所以 test1.txt 還是為空的，兩次修改 test1.txt
此時(shí) dev2 的歷史記錄為
切換到 master 分支，并創(chuàng)建分支 dev1 并修改文件 test1.txt，然后分別提交
然后再修改一次，然后第二次提交
此時(shí) dev1 的日志記錄如下
此時(shí)切回到 master 分支，自行也修改并提交兩次 test1.txt 的修改
此時(shí) master 分支的記錄為
直至，準(zhǔn)備工作完整，我們打包一份，保留 2 個(gè)一模一樣的項(xiàng)目，一個(gè)測(cè)試 git merge，一個(gè)測(cè)試 git rebase
使用 git merge 進(jìn)行合并測(cè)試
步驟說(shuō)明：
- 切換到 master 分支，先合并 dev1 到 master，再合并 dev2 到 master
- 因?yàn)?dev1、dev2 和 master 原本分支都有修改到 test1.txt 的同一行，所以會(huì)出現(xiàn)多次的合并沖突，需要手動(dòng)解決
- 合并完成之后，查看 git merge 的 master 的日志
創(chuàng)建時(shí)現(xiàn)有 dev2 的提交，但是合并時(shí)，先合并 dev1
合并 dev1 到 master，出現(xiàn)沖突
手動(dòng)解決沖突并提交
再合并 dev2 到 master，依然報(bào)沖突
手動(dòng)解決并提交
至此，使用 git merge 已把 dev1 和 dev2 合并到 master 分支，查看 master 分支的日志。
至此使用 git merge 合并和解決沖突測(cè)試完成。
使用 git rebase 合并沖突
使用之前的備份項(xiàng)目測(cè)試 git rebase
步驟說(shuō)明：
- 切到 dev1 分支，rebase dev1 到 master，解決合并沖突
- 切回 master 分支（此時(shí) master 的日志還沒(méi)變），進(jìn)行一次快速合并到 dev1（現(xiàn)在就變了）
- 切到 dev2 分支，rebase dev2 到 master，解決合并沖突
- 切回 master 分支，進(jìn)行一次快速合并到 dev2
- 合并完成之后，查看 git rebase 的 master 的日志
切回 dev1 分支，rebase dev1 到 master，會(huì)產(chǎn)生沖突。
修改成以下內(nèi)容之后，再執(zhí)行 git add .(沒(méi)有執(zhí)行 commit),然后繼續(xù)進(jìn)行 rebase
繼續(xù)進(jìn)行 rebase，則彈出第二次沖突提示
從文本來(lái)看，因?yàn)橛袃尚惺菦_突的，第一次解決沖突是 master 中于 dev1 第一次提交有沖突的內(nèi)容，現(xiàn)在報(bào)的是與 dev1 第二次提交有沖突的內(nèi)容，同樣手動(dòng)解決，然后繼續(xù)，可見(jiàn) rebase 完成。
至此，使用 rebase，已經(jīng)把 dev1 上的兩次提交的修改變基到了 master 分支的提交修改上。
現(xiàn)在切回 master 分支（當(dāng)然，此時(shí) master 的日志還沒(méi)變），進(jìn)行一次快速合并到 dev1（現(xiàn)在就變了）
同樣的，再合并 dev2，同樣解決兩次沖突，
第一次沖突
解決如下
第二次沖突
解決如下：
合并完成
同樣，現(xiàn)在切回 master 分支，進(jìn)行一次快速合并到 dev2，查看日志
git merge 和 git rebase 的結(jié)果對(duì)比
使用 git rebase 后，3 個(gè)分支的歷史記錄如下
git merge 歷史記錄如下
總結(jié)
git merge 和 git rebase 進(jìn)行合并的區(qū)別：
- 歷史記錄不同
- git merge 保留了各個(gè)分支各自的提交記錄，如果有解決沖突，會(huì)單獨(dú)創(chuàng)建一次 commit 記錄沖突的解決，歷史記錄完整。
- git rebase 只有一根線的分支記錄歷史，手動(dòng)解決的沖突不會(huì)創(chuàng)建保留記錄，歷史記錄清晰簡(jiǎn)單
- 操作步驟不同
- git merge 操作簡(jiǎn)單，
- git rebase 操作步驟繁瑣。
- 影響范圍不同
- git merge 操作未對(duì) dev1 和 dev2 的項(xiàng)目?jī)?nèi)容（或提交記錄）進(jìn)行異動(dòng)，不會(huì)影響后續(xù)人員對(duì)此兩個(gè)分支進(jìn)行接續(xù)作業(yè)。
- git rebase 操作已經(jīng)對(duì) dev1 和 dev2 分支進(jìn)行了異動(dòng)，如果有后續(xù)分支使用了這兩個(gè)分支，可能會(huì)導(dǎo)致提交歷史記錄的混亂和其它異常情況。
建議：
只對(duì)尚未推送或分享給別人的本地修改執(zhí)行變基操作清理歷史，不要對(duì)已推送至別處的提交執(zhí)行變基操作。
個(gè)人建議
對(duì)于合并，如果始終不清楚 merge 和 rebase 的區(qū)別，推薦使用 merge。
merge 的一大優(yōu)點(diǎn)是簡(jiǎn)單，不會(huì)對(duì)其它分支造成影響。
唯一可能的不足就是會(huì)有比較多（不清晰）的提交記錄，這一點(diǎn)可以使用 git rebase -i <commit id="" style="box-sizing: border-box;">，進(jìn)入 interactive 模式（后續(xù)文章有介紹），對(duì)歷史記錄進(jìn)行修改</commit>
新手提醒：如果需要合并的分支還有未提交的修改，是沒(méi)有辦法合并的。
Bonus：修改分支的名字
假如從 master 分支創(chuàng)建了一個(gè) feature-branch 分支，結(jié)果寫(xiě)成了 future-brunch
直接使用git branch -m參數(shù)修改即可
git branch -m future-brunch feature-branch
