git工作流程：一次性合併和git-rerere - 有什麼意義？

Question

與大多數新來Git的人一樣，我試圖破譯適用於git merge和git rebase的用例，我有一些混淆。我想我終於決定，就所得到的工作副本狀態而言，他們給你同樣的東西。而且，它們都會導致相同的衝突。如果這不正確，請舉一個例子來啓發我。

從我的角度來看，使用rebase代替merge（如果您的更改沒有被推或拉）的主要好處是保持歷史線性。我真的不明白的是開發git-rerere的原因。

從手冊中，git-rerere應該在您嘗試解決您之前解決的衝突的情況下爲您提供幫助。我要參考的例子是http://www.kernel.org/pub/software/scm/git/docs/git-rerere.html。

如果您的項目策略是不是不斷地將主線上的更改合併到主題分支（如Linux內核）中，則上述示例說明創建「拋棄」合併提交。從本質上講，將主人合併到你的主題中，運行測試以確保一切仍然有效，然後執行「git reset --hard HEAD ^」，主要是將合併提交丟掉。稍後，當您創建另一個「拋棄」合併提交時，git-rerere可幫助您解決您在第一次拋棄合併中已經解決的衝突。

有人可以解釋爲什麼，而不是經歷創建臨時合併提交的所有麻煩，開發人員不會只是將他的主題重定位到主？這不就是git-rebase的要點 - 獲取更改，但避免合併？這是不是完成了同樣的事情，並假設沒有人拉動你的主題分支變化，這不是一個更簡單的方法嗎？拋出合併+ git-rerere工作流真正適用於您的更改已被推入/拉出的情況嗎？

最後一個問題 - 引用Linus的話說：「但是如果我在你的日誌中看到很多'Merge branch linus'，我不會從你那裏拉，因爲你的樹顯然有隨機廢話那不應該在那裏......「Linus也會遇到不斷變硬的問題嗎？

Answer 1

你是正確的，重定位和合並可以產生相同的最終樹。不過，它們產生的歷史是非常不同的，版本控制當然是關於歷史的。你已經表達了對線性歷史的偏好;這在本地範圍內的確是可取的，而合併有助於記錄功能的更大規模交互，錯誤修正等。

答案很簡單，你的核心問題（爲什麼不直接變基）的是，有時候有一個分支開始正確的地方，如果是那樣的話，你應該合併，不重訂。

例如，你可以有它適用於維護版本以及當前版本中修正錯誤;你想從最新的提交中分離出來，這是兩個發行版的祖先。您無法沿着主服務器或維護分支轉發該分支，否則您將無法再將其合併到另一個分支中。

同樣，所有主題分支從某處開始。在某個時候，你想保留這段歷史。你提到了其中一個明確的案例（其他人已經拉上了你的工作），但它可能不太明顯。也許有一些與其他功能的交互，也許這個功能有子功能，並且你正試圖保留整個層次結構。

所以，當然，如果分支是本地的，也沒有理由認爲它的基礎固定的，它是像你說的更簡單，只是變基並完成。但有時候這不是正確的做法。

你的最後一個問題實際上是對某件事情非常不同的，無關的合併衝突。萊納斯說in the context合併，其中不需要做。這是分支和合並哲學的一個非常重要的問題。關於這個問題，Junio Hamano寫了一個excellent blog post。一個簡短的報價且其手頭總結了話題：

當你合併一個特性分支「附加了frotz」你「主人」分支，顯然是結合新「了frotz」功能，但更重要的是，你是說，它希望有一個「了frotz」中的「主人」分支功能

萊納斯不希望看到你這個合併奇分支稱爲「萊納斯」所有的時間，因爲你清楚」不要合併您的分支中需要的某個特定主題。你不斷地將上游分支合併到主題分支中，這完全是錯誤的方向。你不需要所有的主人（或linus）來發展你的話題。你應該完成你的話題，然後以另一種方式合併它，上游到主人！您的主題分支中的的所有內容都不需要。 （和一個開發者的主人真的是一個話題分支，只要積分的關注。）

那麼，萊納斯不必頻繁合併的問題;他在無意義的和適得其反的合併方面存在問題。 （一般來說，如果你確定你的合併是有充分理由完成的，那麼他們就不會很頻繁了 - 而且他們幾乎永遠不會成爲下游合併。）如果你的rebase完成了一個很好的理由，並且他們創造了歷史更好，那麼他們是一件好事，無論頻繁。

Answer 2

這不是完成相同的事情，並假設沒有人拉動你的主題分支變化，這不是一個更簡單的方法嗎？拋出合併+ git-rerere工作流真正適用於您的更改已被推入/拉出的情況嗎？

你已經擊中了頭部。重新發布對於尚未發佈的分支來說很有用; rerere對您已發佈的分支機構（即重新分配不合適/下游開發人員煩人的分支機構）非常有用。

Linus也會遇到不斷變硬的問題嗎？

不，因爲重新綁定不會導致合併提交，並且從表面上看，您看不到分支已重新分配，而您可以輕鬆查看分支是否已多次合併到另一分支中。

Answer 3

每個功能部件的分支工作流程建議存在臨時集成分支。在這種情況下，如果您重新綁定，則必須重新綁定（或拉出）臨時分支，後者可以在最終版本中設置不同的簽入。讓你的rebase實際上沒用。或者就此而言，如果你確實拉入了分支，那麼這種拉動可能變得毫無用處。

Rerere雖然將有助於大大緩解經常性的合併疼痛。