社区中长期以来一直在争论我们应该使用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源创计划”，欢迎正在阅读的你也加入，一起分享。