所以我有一个名为 feature 1 的分支，作为合并到 dev 的拉取请求的一部分，我在那里做了一些工作。
还有另一个名为 feature 2 的分支，它是我正在处理的页面被重构的不同拉取请求的一部分。
让feature 2 进入feature 1 分支的最佳方法是什么？我应该分支feature 2，将feature 2 合并到feature 1 分支，还是将feature 1 重新定位到feature 2？
【问题讨论】：
标签： git merge branch rebase pull-request
假设您的分支情况如下所示：
A---B feature2
/
o---o---o dev
\
C---D---E feature1
你想要的是rebase你在feature1中的工作在feature2之上：
A---B feature2
/
o---o---o dev
\
A'---B'---C'---D'---E' feature1
为此，您可以运行：
git rebase feature2 feature1
这基本上是说“checkout feature1 并将其重新定位在 feature2 之上”。当然，准备好解决您和feature2的作者修改的页面中不可避免地出现的冲突。
你可能想知道为什么要变基？好吧，因为无论哪个分支首先合并到dev，它都会产生清晰的历史记录。
比如我们考虑feature2在feature1之前合并的场景：
A---B feature2
/ \
o---o---o---o dev
\
A'---B'---C'---D'---E' feature1
在这种情况下，一旦你在 dev 之上 rebase feature1，Git 将检测到提交 A 和 B 引入的更改已经在 dev 中，因此它将从 @ 中删除它们987654338@:
A---B feature2
/ \
o---o---o---o dev
\
C'---D'---E' feature1
如果feature1 在feature2 之前被重新定位会怎样：
A---B feature2
/
o---o---o-----------------------o dev
\ /
A'---B'---C'---D'---E' feature1
这里同样适用。一旦你在dev 之上重新设置feature2，A 和B 将从feature1 中删除，因为它们的更改已经存在于dev 中：
o---o---o---------------------o dev, feature2
\ /
A'---B'---C---D---E feature1
当然，如果在您将 feature1 重新设置为基础之后，在 feature2 中添加了新的提交，这些提交仍将保留：
F---G---H feature2
/
o---o---o---------------------o dev
\ /
A'---B'---C---D---E feature1
【讨论】：
首先，拉取请求不是 git 协议的一部分。拉取请求只是由 GitHub 等 git 托管服务实现的，用于在合并之前提供审查功能。如果您的问题实际上与任何与拉取请求相关的功能有关，那么您还必须告诉我们您正在使用什么托管服务。但是，在我的理解中，您的问题可以归结为 merge 和 rebase 之间的区别是什么，而这两个功能都是 git 协议的一部分。
分支的当前状态可以认为是分支指向的提交之前的所有提交的总和。与数学求和一样，最终结果并不取决于您对项目求和的顺序，这是考虑合并和变基之间唯一区别（种类）的一种方式。所以，如果你只关心当前版本分支的最终结果，那就停止阅读，做你认为最简单的事情。
变基和拉取请求之间的区别在于历史记录的外观。 feature-1 到 feature-2 的变基从 feature-2 创建一个新分支，并将 feature-1 上的所有提交复制到新分支，然后删除 feature-1 分支并将新分支重命名为 feature-1。所以它不再是相同的提交。它们是相同的，但它们不再相同并且它们具有不同的哈希值。一般来说，这会创建一个更清晰的历史记录，但在某种程度上它是一个不太真实的历史记录，因为它看起来好像分支 feature-1 总是由 feature-2 创建的，但它不是。
从feature-2 到feature-1 的合并将创建与feature-1 分支的当前版本相同的最终结果，但历史将显示分支feature-1 最初是从main/master 创建的, 对其进行了提交，然后将 feature-2 合并到其中，然后将 feature-1 和 feature-2 合并回默认分支。
因此，最终结果将是相同的，这只是您希望存储库历史讲述什么故事的问题。对于很多人来说，这并不重要。
【讨论】：