Git merge或git rebase？

Question

我已經閱讀了git plain merge適合某些情況，而git rebase在Git中進行合並時適合其他情況。

但我不知道如果一個rebase可以替代合並。 在重新分支一個分支后，它仍然需要一個合並，這更可能是一個快速合並。 據我所知，Rebase只是用來“保證”快速合並 - 它不能代替git merge。 正確？

Answer 1

這基本上是它（或者，至少是使用rebase的一個原因）。 它保證了快速合並。 （我還發現在重新定位時更容易解決沖突，因為反對合並，尤其是在使用git rerere 。）

Answer 2

請注意，您最終提交的最終提交指向的快照，無論是rebase的最后一次重新提交提交還是合並后的最后一次合並提交，都是相同的快照 - 它只是不同的歷史記錄。 重新引用按照引入的順序重放從一行工作到另一行的更改，而合並則使用端點並將它們合並在一起。

以上是一個很好的總結！

Answer 3

我會說這兩件事在他們的運作中根本不同，並且實現了類似的事情。

git rebase將您的提交列表放在另一個分支的頂部。 因此，按照您定義的順序（如果使用--interactive ）進行沖突解決，如果您沒有完全正交，則每次提交都會產生沖突（即：提交可能不適用，因為它們中的每一個都是單獨應用的）。 請注意 ，您還可以將多個提交合並為一個提交 - 所謂的壓縮 - 在重新設置時。

git merge有不同的策略，它結合了多個分支。 另請參閱合並幫助，以了解您可以選擇自動沖突解決策略（我將選擇一些並粘貼部分摘要）：

• ours ：這個選項通過支持我們的版本強制沖突的帥哥干凈地自動解決。
• octopus ：這解決了具有兩個以上頭部的情況，但拒絕進行需要手動解決的復雜合並。
• subtree ：這是一種修改后的遞歸策略。 當合並樹A和B時，如果B對應於A的子樹，則首先調整B以匹配A的樹結構，而不是讀取相同級別的樹。

話雖這么說，一rebase只是一個選項，當沒有人看到你的變化，只要它會改變提交哈希和合並是永遠適用。 另請注意，如果您有審核流程，則可以選擇更改更改歷史記錄以反映日志中的意圖。

Answer 4

我想這篇來自Git Bucket的文章會給你答案。

合並與重新定位

關於git rebase的第一件事就是它解決了與git merge相同的問題。 這兩個命令都旨在將更改從一個分支集成到另一個分支 - 它們只是以非常不同的方式進行。

合並很好，因為它是一種非破壞性的操作。 現有分支機構不會以任何方式更改。 這避免了變基的所有潛在缺陷（下面討論）。

另一方面，這也意味着每次需要合並上游更改時，功能分支將具有無關的合並提交。 如果master非常活躍，這可能會嚴重污染您的功能分支的歷史記錄。 雖然使用高級git日志選項可以緩解這個問題，但是它可能使其他開發人員難以理解項目的歷史記錄。

變基的主要好處是可以獲得更清晰的項目歷史。 首先，它消除了git merge所需的不必要的合並提交。 其次，正如您在上圖中所看到的，變基也會產生完美線性的項目歷史記錄 - 您可以在沒有任何分支的情況下跟蹤功能的提示一直到項目的開頭。 這樣可以使用git log，git bisect和gitk等命令更輕松地導航項目。

但是，這個原始的提交歷史有兩個權衡：安全性和可追溯性。 如果您不遵循重新規定的黃金法則，重寫項目歷史記錄可能會對您的協作工作流程造成災難性后果。 而且，不太重要的是，rebase會丟失合並提交提供的上下文 - 您無法看到上游更改何時合並到功能中。