Question

我对此感到困惑。在以下场景中，在将其推回到repo之前，您最好如何将本地功能分支添加回主分支？请注意，我没有在终端上使用git，我使用的是sourcetree，所以我对git术语不是很熟悉。

情景A ：团队中没有人将更改推送到主

Master                A
                       \
Feature branch          B - C - D

情景B：当我在当地分行工作时有人推动了改变

Master                A - E
                       \
Feature branch          B - C - D

Answer 1

方案A很简单，因为从功能分支到master的正常推送应该成功完全没有问题。在方案B中，如果我们试图简单地推送Git将告诉我们我们的功能分支落后于master。解决这个问题的两种主要方法是合并和重新定位。

对于合并选项，我们可以将master分支合并到我们的功能中，然后将功能合并到master。以下是用于将master合并到功能分支中的Git命令：

git checkout feature
git merge origin/master

这是一个图表，显示了合并选项的最终结果：

master:  A ---------- E ---- N
          \             \   /
feature:   B -- C -- D -- M

此处M是将master合并到要素分支中的合并提交。我们需要这样做才能使功能分支与远程master保持同步。然后，为了将我们的更改带入master，我们也在master中进行了合并提交。

从功能上讲，合并可以完成工作，但正如您从历史中看到的那样，并不总是在Git中开展业务的最整洁方式。合并的替代方法是变基：

git checkout feature
git rebase origin/master

这就是变基会的样子，我强调你可以在图表中看到的内容：

master:  A -- E
          \
feature:    B -- C -- D

rebase的第一步是将功能分支回滚到功能和master之间的最新祖先提交，然后在功能分支顶部从master播放新提交：

master:  A -- E
          \
feature:   E        [B, C, D commits not yet reapplied]

接下来，我们在新基础上重新应用您的唯一提交：

master:  A -- E
          \
feature:   E -- B' -- C' -- D'

我们可以按如下方式重写：

master:  A -- E
                \
feature:          B' -- C' -- D'

现在请注意，功能分支完全是master的提前。现在推送或拉取请求应该完成而没有任何冲突。