git的Rebase和Merge之间的区别

有人会说Merge更好，因为它保留了最完整的工作历史。其他人则认为，Rebase变得更整洁，这使审阅者的生活更轻松，更高效。本文将解释合并和重新设置之间的区别是什么，使用它们之一有什么好处。

从根本上讲，合并和rebase提供了相同的目的，以将来自一个分支（有时倍数分支）的变化集成到另一个分支中。最常用的是在打开Pull请求之前将最新的Master或开发分支集成。虽然目的是相同的，但Merge和Rebase达到的方式不同。

想象一下，您有一个这样的分支“功能”，它是从“基础”的“开发”分支出来的。从那时起，您就完成了C，D，E的工作，并且对develop进行了2个更改，即A，B。现在，您想打开一个pull请求，将“您的功能”集成到“ develop分支”中。。在此之前，您必须将“开发分支”中的更改集成到“您的功能分支”中，这样您的拉取请求中就不会出现冲突。

Merge

合并将在您的特征分支中将更改集成，并创建一个新的提交F. F是合并开发分支的提交，如果有的话，对冲突进行排序。此方法将为特征分支带来Develp分支的更改，即A和B。现在，您的特征分支上的提交是C，A，D，B，E，F.有3个添加到您的功能分支中的其他提交。

Rebase

另一方面，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中。这很容易导致混乱。