Git变基导致拉取请求在自动合并时失败

Question

我正在我的分支B上开发一个功能，我使用了变基策略将主分支的更改合并到B分支。

今天，当我将主分支变基到B分支时（B分支没有来自上游的更改），我不得不强制推送这些更改到我的分支（在此之前，正常推送失败）。

然后，我从我的B分支向其他开发人员也在工作的Master repos B创建了一个拉取请求，但是该拉取请求无法自动合并。

如何最好地处理这些情况？

- Anuruddha

Answer 1

与同行交谈。

你刚刚重写了历史，所以不要期望你的远程分支能够自动合并。这也是你不得不强制推送分支的原因。

下面是情景描述：假设master上有3个新修改。历史记录看起来像这样：

new3 *  * branchWork2
new2 *  * branchWork1
new1 * /
base *

在执行git rebase master之后，你的历史记录现在是这样的：

branchwork2' *
branchwork1' *
new3         *
new2         * 
new1         * 
base         *

你并没有失去分支上的任何工作，但它们并不是完全相同的提交；它们将产生不同的SHA。

通常情况下，如果没有人依赖于你的工作，这不会是一个问题。当你尝试重新基于公共分支重组你的工作时，这通常就是情况所在。然而，如果有人依赖了你的工作，那么他们现在必须将自己所做的工作与你推送的“旧”历史和“新”的历史进行调和，这将带来一些麻烦。

在这种情况下，请确保与同事协调沟通，以确保他们清楚这种情况，并且有足够的能力来解决任何复杂的合并冲突。

- Makoto

---

此外，记住一个有用的准则是避免在其他人正在工作的分支上使用rebase。如果你的分支被其他人共享，rebase会改变git历史记录，这意味着他们将在同一分支上拥有与你不同的git历史记录。 - Kashyap

@Kashyap，您是否建议在这种情况下使用合并而不是变基？那样我们会失去线性提交历史记录吗？ - Anuruddha

@apremalal：再说一遍，这是一个共享分支，所以您不能随意决定重写它的历史记录。您可以在自己的分支上做这个操作，这样会更加安全，因为不会影响其他人。 - Makoto

@Makoto 说得对。但是协作开发一个功能的最佳方式是什么？在这种情况下，我们应该使用“合并”吗？ - Anuruddha

是的。将其视为集成分支，并将工作合并到其中。 - Makoto