社區中長期以來一直在爭論我們應該使用Merge還是Rebase。
有人會說Merge更好，因爲它保留了最完整的工作歷史。其他人則認爲，Rebase變得更整潔，這使審閱者的生活更輕鬆，更高效。本文將解釋合併和重新設置之間的區別是什麼，使用它們之一有什麼好處。
從根本上講，合併和rebase提供了相同的目的，以將來自一個分支（有時倍數分支）的變化集成到另一個分支中。最常用的是在打開Pull請求之前將最新的Master或開發分支集成。雖然目的是相同的，但Merge和Rebase達到的方式不同。
> Image by Author
快速瞭解目標。想象一下，您有一個這樣的分支“功能”，它是從“基礎”的“開發”分支出來的。從那時起，您就完成了C，D，E的工作，並且對develop進行了2個更改，即A，B。現在，您想打開一個pull請求，將“您的功能”集成到“ develop分支”中。。在此之前，您必須將“開發分支”中的更改集成到“您的功能分支”中，這樣您的拉取請求中就不會出現衝突。
Merge
> Image by Author
合併將在您的特徵分支中將更改集成，並創建一個新的提交F. F是合併開發分支的提交，如果有的話，對沖突進行排序。此方法將爲特徵分支帶來Develp分支的更改，即A和B。現在，您的特徵分支上的提交是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)
個人博客網站：https://programmerblog.xyz
本文分享自微信公衆號 - IT技術分享社區（gh_a27c0758eb03）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。