社區中長期以來一直在爭論我們應該使用Merge還是Rebase。

有人會說Merge更好，因為它保留了最完整的工作歷史。其他人則認為，Rebase變得更整潔，這使審閱者的生活更輕松，更高效。本文將解釋合并和重新設置之間的區別是什么，使用它們之一有什么好處。

從根本上講，合并和rebase提供了相同的目的，以將來自一個分支（有時倍數分支）的變化集成到另一個分支中。最常用的是在打開Pull請求之前將最新的Master或開發分支集成。雖然目的是相同的，但Merge和Rebase達到的方式不同。

> Image by Author

快速了解目標。想象一下，您有一個這樣的分支“功能”，它是從“基礎”的“開發”分支出來的。從那時起，您就完成了C，D，E的工作，并且對develop進行了2個更改，即A，B?，F在，您想打開一個pull請求，將“您的功能”集成到“ develop分支”中。。在此之前，您必須將“開發分支”中的更改集成到“您的功能分支”中，這樣您的拉取請求中就不會出現沖突。

Merge

> Image by Author

合并將在您的特征分支中將更改集成，并創建一個新的提交F. F是合并開發分支的提交，如果有的話，對沖突進行排序。此方法將為特征分支帶來Develp分支的更改，即A和B?，F在，您的特征分支上的提交是C，A，D，B，E，F.有3個添加到您的功能分支中的其他提交。

Rebase

> Image by Author

另一方面，rebase會移動整個功能分支，就像它從一開始就從開發分支的最新提交分支出來一樣。Rebase將首先搜索功能分支的基礎，然后將其更改為開發分支B上的最新提交，然后根據該基礎B將所有提交重新應用到功能分支上。Rebase實際上是創建新提交，C’，D’，E’。原始提交保持不變。最后，它將要素分支指向的要素從E更改為E’。

優點

這兩種方法之間的最大區別在于，合并保留了作品的完整歷史記錄，包括按時間順序排列，而Rebase使提交變得整潔，僅與分支上的作品相關。當審閱者審閱您的PR時，如果您選擇合并，她將看到A，B，C，D，E，F提交，如果您選擇Rebase，則只會看到C，D，E。

合并具有較高的可追溯性。無論與該公關相關如何，您都可以找到整個工作歷史。但它可能對審稿人來說是痛苦的，因為該分支包括許多無關的犯罪，并且往往很難識別它們。

Rebase的確可以使PR整潔，干凈且相關，而不會產生嘈雜的提交。審閱者可以輕松了解此PR的含義以及該分支內進行的更改。但是，如果您想跟蹤存儲庫的詳盡歷史記錄，可能并沒有太大幫助。

Merge具有更高的可追溯性，而Rebase則更整潔且易于審核。

那我應該使用哪一個？

這實際上取決于您的組織所采用的工作策略。您必須權衡Rebase的價值與Merge可追溯性的價值。這兩種方法也可能同時應用，在某些情況下請使用某種方法。

根據我的個人經驗，Rebase更為有利，因為它提供了與團隊成員合作的更輕松的方式。而且在大多數時候，我們確實應該避免將與我們的工作無關的提交包含在PR中。這很容易導致混亂。

(本文由聞數起舞翻譯自Christopher Tao的文章《The Differences between Rebase and Merge》，轉載請注明出處，原文鏈接：
https://towardsdatascience.com/the-differences-between-rebase-and-merge-30c91cd18f30)

IT技術分享社區

個人博客網站：https://programmerblog.xyz

文章推薦程序員效率：畫流程圖常用的工具程序員效率：整理常用的在線筆記軟件遠程辦公：常用的遠程協助軟件，你都知道嗎？51單片機程序下載、ISP及串口基礎知識硬件：斷路器、接觸器、繼電器基礎知識

總結

以上是生活随笔為你收集整理的Git：Rebase和Merge之间的区别，看完这篇文章你就懂了！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。