您好,登錄后才能下訂單哦!
這篇文章主要介紹git merge中--ff/--no-ff/--ff-only三種選項參數(shù)的區(qū)別有哪些,文中介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們一定要看完!
我們從一個正常開發(fā)流程來看看:
開發(fā)者小王接到需求任務(wù),從 master 分支中創(chuàng)建功能分支,git 指令如下:
git checkout -b feature556 Switched to a new branch 'feature556'
小王在 feature556 分支上完成的功能開發(fā)工作,然后產(chǎn)生1次 commit,
git commit -m 'Create pop up effects' [feature556 6104106] create pop up effects 3 files changed, 75 insertions(+)
我們再更新一下 README 自述文件,讓版本差異更明顯一些
git commit -m `updated md`
這時候我們看看當(dāng)前分支的 git 歷史記錄,輸入 git log --online -all
可以看到全部分支的歷史線:
f2c9c7f (HEAD -> feature556) updated md 6104106 create pop up effects a1ec682 (origin/main, origin/HEAD, main) import dio c5848ff update this readme 8abff90 update this readme
直接看下圖可能會更好理解一些
功能完成后自然要上線,我們把代碼合并,完成上線動作,代碼如下
git checkout master git merge feautre556 Updating a1ec682..38348cc Fast-forward ....... | 2+++ 1 file changed, 2 insertions(+)
如果你注意上面的文字的話,你會發(fā)現(xiàn) git 幫你自動執(zhí)行了 Fast-forward
操作,那么什么是 Fast-forward
?Fast-forward
是指 Master 合并 Feature 時候發(fā)現(xiàn) Master 當(dāng)前節(jié)點一直和 Feature 的根節(jié)點相同,沒有發(fā)生改變,那么 Master 快速移動頭指針到 Feature 的位置,所以 Fast-forward 并不會發(fā)生真正的合并,只是通過移動指針造成合并的假象,這也體現(xiàn) git 設(shè)計的巧妙之處。合并后的分支指針如下:
通常功能分支(feature556) 合并 master 后會被刪除,通過下圖可以看到,通過 Fast-forward
模式產(chǎn)生的合并可以產(chǎn)生干凈并且線性的歷史記錄:
再說說什么是 non-Fast-forward
剛說了會產(chǎn)生 Fast-forward
的情況,現(xiàn)在再說說什么情況會產(chǎn)生 non-Fast-forward
,通常,當(dāng)合并的分支跟 master 不存在共同祖先節(jié)點的時候,這時候在 merge 的時候 git 默認無法使用 Fast-forward
模式,
我們先看看下圖的模型:
可以看到 master 分支已經(jīng)比 feature001 快了2個版本,master 已經(jīng)沒辦法通過移動頭指針來完成 Fast-forward
,所以在 master 合并 feature001 的時候就不得不做出真正的合并,真正的合并會讓 git 多做很多工作,具體合并的動作如下:
找出 master 和 feature001 的公共祖先,節(jié)點 c1,c6, c3 三個節(jié)點的版本 (如果有沖突需要處理)
創(chuàng)建新的節(jié)點 c7,并且將三個版本的差異合并到 c7,并且創(chuàng)建 commit
將 master 和 HEAD 指針移動到 c7
補充:大家在 git log
看到很多類似:Merge branch 'feature001' into master
的 commit 就是 non-Fast-forward 產(chǎn)生的。
執(zhí)行完以上動作,最終分支流程圖如下:
如何手動設(shè)置合并模式 ?
先簡單介紹一下 git merge
的三個合并參數(shù)模式:
-ff 自動合并模式:當(dāng)合并的分支為當(dāng)前分支的后代的,那么會自動執(zhí)行 --ff (Fast-forward)
模式,如果不匹配則執(zhí)行 --no-ff(non-Fast-forward)
合并模式
--no-ff 非 Fast-forward 模式:在任何情況下都會創(chuàng)建新的 commit 進行多方合并(及時被合并的分支為自己的直接后代)
--ff-onlu Fast-forward 模式:只會按照 Fast-forward
模式進行合并,如果不符合條件(并非當(dāng)前分支的直接后代),則會拒絕合并請求并且推出
以下是關(guān)于 --ff, --no-ff, --ff-only 三種模式的官方說明(使用 git merge --helo 即可查看
):
Specifies how a merge is handled when the merged-in history is already a descendant of the current history. --ff is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the refs/tags/ hierarchy, in which case --no-ff is assumed.
With --ff, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit). When not possible (when the merged-in history is not a descendant of the current history), create a merge commit.
With --no-ff, create a merge commit in all cases, even when the merge could instead be resolved as a fast-forward.
With --ff-only, resolve the merge as a fast-forward when possible. When not possible, refuse to merge and exit with a non-zero status.
三種 merge 模式?jīng)]有好壞和優(yōu)劣之分,只有根據(jù)你團隊的需求和實際情況選擇合適的合并模式才是最優(yōu)解,那么應(yīng)該怎么選擇呢? 我給出以下推薦:
如果你是小型團隊,并且追求干凈線性 git 歷史記錄,那么我推薦使用 git merge --ff-only
方式保持主線模式開發(fā)是一種不錯的選擇
如果你團隊不大不小,并且也不追求線性的 git 歷史記錄,要體現(xiàn)相對真實的 merge 記錄,那么默認的 git --ff
比較合適
如果你是大型團隊,并且要嚴(yán)格監(jiān)控每個功能分支的合并情況,那么使用 --no-ff
禁用 Fast-forward
是一個不錯的選擇
以上是“git merge中--ff/--no-ff/--ff-only三種選項參數(shù)的區(qū)別有哪些”這篇文章的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對大家有幫助,更多相關(guān)知識,歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。