總述

代碼合入流程用于減輕代碼合入復(fù)雜度、簡(jiǎn)化主分支歷史（具有線性的歷史）、保證合入代碼對(duì)主分支的HEAD有效。
代碼合入分為兩步

• 解決沖突：將需要合入的分支變基到目標(biāo)分支之上。保證合入代碼對(duì)目標(biāo)分支的HEAD有效。此時(shí)會(huì)解決所有代碼沖突。
• 執(zhí)行合入：向目標(biāo)分支提交merge請(qǐng)求，執(zhí)行合入CI后完成合入。

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

• Squash。如 feature分支 向 dev分支 合入；存在沖突的合入。此時(shí)會(huì)出現(xiàn) 合入過程沖突多、合入結(jié)果復(fù)雜（commit多）、合入message不清晰（未能完整描述改動(dòng)內(nèi)容）的問題。此時(shí)不需要保存歷史commit，僅需要干凈的將feature合入master。
• Rebase。如 hotfix分支 向 dev分支 合入；feature分支 向 feature分支 合入。此時(shí)沖突少、合入結(jié)果簡(jiǎn)單、需要保存歷史commit。

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

Rebase解決沖突

適用情況

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

其中commit數(shù)量少（1~2個(gè)），開發(fā)周期短（1day）。

操作方式

其中dev分支向master分支合入。通過執(zhí)行 git log --all --graph --decorate 可看到如下圖。兩個(gè)分支已經(jīng)分開，如果通過在master分支git merge合入且存在沖突，那么會(huì)觸發(fā)三方合并在master生成merge commit污染主分支提交歷史，這是我們不想看到的。

此時(shí)我們執(zhí)行以下流程解決問題

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

此時(shí)可以看到master分支和dev分支干凈得合在一起。經(jīng)過單元測(cè)試并確認(rèn)我們的改動(dòng)沒有bug后，我們可以push并開啟mr。

Squash解決沖突

適用情況

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

其中commit數(shù)量多（> 2個(gè)），開發(fā)周期長(zhǎng)（> 1day），沖突量大（每個(gè)commit可能都有沖突）。

操作方式

此處仍然是將dev合入master。其中dev分支提交歷史混亂（有tmp提交），commit號(hào)多且每個(gè)commit都與master有沖突。此時(shí)在master分支執(zhí)行 git merge dev 會(huì)觸發(fā)三方合并，且保留不必要的commit歷史。不必要的提交信息如圖

操作的初始狀態(tài)如圖

此處我們執(zhí)行如下操作，在master分支解決沖突并壓縮提交。隨后checkout一個(gè)提交分支并開啟mr。這有利于簡(jiǎn)化主分支提交。但需要小心，dev分支不能再使用，需要重新從master分支拉取新的dev。

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

mater結(jié)果如圖

Merge執(zhí)行合入

這里強(qiáng)調(diào)使用merge no fast forward的目的是保留合入信息。

git checkout master
git merge --no-ff dev

以上就是Git的代碼合入流程詳解的詳細(xì)內(nèi)容，更多關(guān)于Git代碼合入流程的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論