Git的代碼合入流程詳解

Posted on by

總述

代碼合入流程用於減輕代碼合入復雜度、簡化主分支歷史（具有線性的歷史）、保證合入代碼對主分支的HEAD有效。
代碼合入分為兩步

  • 解決沖突：將需要合入的分支變基到目標分支之上。保證合入代碼對目標分支的HEAD有效。此時會解決所有代碼沖突。
  • 執行合入：向目標分支提交merge請求，執行合入CI後完成合入。

其中第一步“解決沖突”的方法分為兩種種情況：

  • Squash。如 feature分支 向 dev分支 合入；存在沖突的合入。此時會出現 合入過程沖突多、合入結果復雜（commit多）、合入message不清晰（未能完整描述改動內容）的問題。此時不需要保存歷史commit，僅需要幹凈的將feature合入master。
  • Rebase。如 hotfix分支 向 dev分支 合入；feature分支 向 feature分支 合入。此時沖突少、合入結果簡單、需要保存歷史commit。

其中第二步“執行合入”應采用 merge no-fast-forward 的方式。確保合入信息可追溯和易回退。

Rebase解決沖突

適用情況

  • hotfix → develop
  • feature → feature
  • develop → master

其中commit數量少（1~2個），開發周期短（1day）。

操作方式

其中dev分支向master分支合入。通過執行 git log –all –graph –decorate 可看到如下圖。兩個分支已經分開，如果通過在master分支git merge合入且存在沖突，那麼會觸發三方合並在master生成merge commit污染主分支提交歷史，這是我們不想看到的。

此時我們執行以下流程解決問題

git checkout dev  && git pull dev
git rebase master // 保證master與remote倉庫一致
// 若發生沖突執行 git mergetool  解決沖突
git rebase --continue

此時可以看到master分支和dev分支幹凈得合在一起。經過單元測試並確認我們的改動沒有bug後，我們可以push並開啟mr。

Squash解決沖突

適用情況

  • feature → develop
  • gitlab → gerrit （此處為泊車自動同步代碼中用到）

其中commit數量多（> 2個），開發周期長（> 1day），沖突量大（每個commit可能都有沖突）。

操作方式

此處仍然是將dev合入master。其中dev分支提交歷史混亂（有tmp提交），commit號多且每個commit都與master有沖突。此時在master分支執行 git merge dev 會觸發三方合並，且保留不必要的commit歷史。不必要的提交信息如圖

操作的初始狀態如圖

此處我們執行如下操作，在master分支解決沖突並壓縮提交。隨後checkout一個提交分支並開啟mr。這有利於簡化主分支提交。但需要小心，dev分支不能再使用，需要重新從master分支拉取新的dev。

git checkout master // 保證master與remote一致
git merge --squash dev
// 解決沖突  git mergetools  、  git commit -m <總結此次提交的所有內容>
git checkout -b <mr-branch>
git push xxxx

mater結果如圖

Merge執行合入

這裡強調使用merge no fast forward的目的是保留合入信息。

git checkout master
git merge --no-ff dev

以上就是Git的代碼合入流程詳解的詳細內容，更多關於Git代碼合入流程的資料請關註WalkonNet其它相關文章！

推薦閱讀：