Git的程式碼合入流程詳解

2022-11-15 14:01:31

總述

程式碼合入流程用於減輕程式碼合入複雜度、簡化主分支歷史（具有線性的歷史）、保證合入程式碼對主分支的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程式碼合入流程的資料請關注it145.com其它相關文章！

Git的程式碼合入流程詳解

目錄

總述

Rebase解決衝突

適用情況

操作方式

Squash解決衝突

適用情況

操作方式

Merge執行合入

熱門文章