应该使用什么git命令来为PR准备分支？

Question

嘿-我有一个看起来很简单的问题，但我很难理解它，试图找到答案会导致许多相似但微妙不同的问题的答案。

我一直在开发master的一个老分支上的一个特性，而其他团队成员则在管理一个巨大的拉力。现在它们已经完成了，我需要准备好我的功能来提出一个拉取请求。

我需要从我的分支中获取相关的更改(分布在10-15个提交中的3-4个文件中)，并将它们与master中的大量更改(分布在数十个文件中的数十个或数百个提交)集成在一起。在我的文件版本和它们的版本之间会有合并冲突，但它们很容易解决。传统的方法是什么来捕获我的分支(或者创建一个结合master +旧分支的新分支)并解决冲突？我开始重新建立基础，但最终不得不解决从fork开始在master中发生的每一次提交，这似乎完全没有必要，也很耗时。

谢谢!

Answer 1

执行此操作的典型方法是使用git pull master进入您的分支并解决冲突。然后git push你的分支。这使得拉取请求不那么头疼。

Answer 2

作为TriskalJM stated，通常的方法是git pull master进入你的分支，然后是git push，然后是PR。但是，在您的用例中，正如您所说的，rebase可以让您在每次提交的基础上处理冲突。我建议您根据实际结果检查一些方法。

我认为单独处理master分支和旧功能分支的合并是有意义的，因为新的更改与旧的更改是分开的。为此，您可以尝试将您在功能分支上所做的更改选择到主分支上(或者更好地从主分支创建一个新分支，在其上进行选择，然后与结果合并，以检查它是否独立)。如果对你来说更清楚，你也可以尝试一下：

1. 从feature 创建一个新的分支，但是从之前的最后一次提交开始。让我们称它为feature1.
2. Merge feature1，处理从feature on to feature 1.
3. Check results publish to master的提交。

对于带有rebase分支的merge，您可以选中一个选项，即对于第一个中出现的simple feature方法也是有效的。我指的是merge和rebase命令的strategy选项。

通过使用git rebase ... -s recursive -X theirs“强制冲突块通过偏爱其版本而被自动干净地解决”(在本例中为theirs=master )。

注意1:注意到这在文档上可能有点混乱，有一种称为ours的合并策略和一种称为递归的策略，其中包含一个名为ours (或我的提案中的theirs )的选项。git merge ... -s ours <> git merge ... -s recursive -X ours