合並分支時使用pull和no-ff時快進

Question

我的工作流程中有許多短命分支，我希望它們能夠分開。 所以，我打算使用git config --add merge.ff false 。 但是，當我正在進行拉（我理解為fetch + merge）時 - 然后我想要一個快進行為，以避免不必要的額外提交。

這是一件好事嗎？ 這可能嗎？

Answer 1

注意：Git 2.0（2014年第2季度）將使用commit b814da8引入config push.ff ：

pull.ff::

默認情況下，Git在合並作為當前提交的后代的提交時不會創建額外的合並提交。 相反，當前分支的提示是快進的。

• 當設置為false時，此變量告訴Git在這種情況下創建額外的合並提交（相當於從命令行提供--no-ff選項）。
• 設置為only時，僅允許此類快進合並（相當於--ff-only提供--ff-only選項）。

---

初步答復（2012年10月）

試試：

git pull --ff

它應該優先於您的合並配置設置。
它會將--ff選項傳遞給git pull命令中的底層合並。

請注意--no-ff選項，如“ 了解Git工作流程 ”中所述

有了足夠的標記，你可以強制Git以你認為的方式行事而不是它想要的方式。 但這就像使用像錘子一樣的螺絲刀; 它完成了工作，但它做得很差，需要更長時間，並損壞螺絲刀。

考慮一下常見的Git工作流程如何分崩離析。

Create a branch off Master, 
do work, 
and merge it back into Master when you’re done

大多數情況下，這種行為與您期望的一樣，因為Master在您分支后發生了變化。 然后有一天你將一個功能分支合並到Master中，但Master沒有分歧。 Git不是創建合並提交，而是將Master指向功能分支上的最新提交，或“快進”。（圖）

不幸的是，您的功能分支包含檢查點提交，頻繁提交以備份您的工作但捕獲處於不穩定狀態的代碼。 現在這些提交與Master的穩定提交無法區分。 你可以很容易地重新陷入災難。

因此，您添加了一條新規則：“當您在功能分支中合並時，請使用–no-ff強制執行新提交。”這樣可以完成工作，然后繼續。

然后有一天你發現了生產中的一個關鍵錯誤，你需要追蹤它何時被引入。 你運行bisect但繼續登陸檢查點提交。 你放棄並手工調查。

您將錯誤縮小到單個文件。 你跑blame ，看看它在過去48小時如何變化。 你知道這是不可能的，但是blame報告文件在幾周內沒有被觸及。
事實證明， blame報告了初始提交時間的變化，而不是合並時的變化 。 您的第一個檢查點提交在幾周前修改了此文件，但此更改已於今天合並。

no-ff的創可貼，破碎的二等分和責備神秘都是你用螺絲刀作為錘子的症狀。

有關更多信息，請參閱

• “ 使用dvcs / git，單個提交是否優先於多個小型主題提交？ ”
• “ git newbie question - 提交方式：一次或一次提交所有已更改的文件？ ”