作者 | Video++極鏈科技後端Team
一般來說,在單人開發的情況下,merge通常會產生快進(fast-forward)方式的合併。如果在子分支(feature)被創建之後,父分支(master)未產生新的修改和提交,此時把feature合併回master,Git會在提交鏈上把master指針簡單的前移,使兩個分支進度同步,並形成無分支記錄的提交鏈。執行時在控制台輸出Fast-forward標識。這種merge方式下不會產生衝突,git log命令會看到如下記錄:
看到這裡,可能有人會有疑問,工作空間中自始至終只出現了兩個分支,為什麼會是三路合併。從git 源碼中可以找到merge執行的入口,它有這樣的方法簽名:
three-way merge機制有一定的隱患。如果其中一個待合併分支,比如ours,和ancestor版本的某一部分代碼相同,但另一個待合併分支theirs中有不同的修改,合併的結果就會採用theirs分支不同的那部分,並不會依照修改的時間順序來決定最終內容。在實際項目中可能會反覆修改同一段代碼來響應需求變更,就有幾率發生這種合併結果與預計不符的情況,需要特別留意。
除了原本的多分支記錄變為了直線提交鏈,還可以注意到,其中原本在feature分支上的提交,rebase後的SHA編碼發生了變化。rebase消除了真實歷史,重新生成了新的提交。
這裡選擇合併第一個和第三個,丟棄第二個提交。
對於使用rebase還是merge來合併代碼,實際並沒有什麼固定的模式,取決於開發者如何看待倉庫的歷史記錄。一些人認為歷史記錄應該反映全部真實變更細節,而另一些人認為歷史記錄應該是精心維護的變更目錄。具體如何使用取決於項目合作者的一致共識。無論是merge還是rebase,都應該了解其中原理,避免危險操作,才能享受到Git諸多特性帶來的便利。
推薦閱讀: