Git 如何修复级联分支的重定基混乱

我们有一个工作流，只有一个团队成员在多个功能分支上工作。工作就是这样，下一个分支都依赖于上一个分支。默认分支是

develope

我们可以这样说：

他创建

featureA

分支，完成工作，推动分支，并在GitHub上创建PR

他创建

featureB

分支（基于

featureurea

one），完成工作并对其进行PRs

他创建了

featureC

分支（基于

featureB

）来完成工作并对其进行PRs

他创建了

featureD

分支（基于

featureC

）来完成工作并对其进行PRs

没有一个PRs被合并

现在，项目经理介入并开始合并。合并方式如下：

项目经理将

featureA

合并到开发中

开发人员在其方面做了以下工作：

git checkout develop
git fetch origin
git rebase origin/develop
git checkout featureB
git rebase origin/develop
git push origin featureB

此时，我们得到一个错误：

machine /c/Work/ (featureB)
$ git push origin featureB
To https://github.com/x.git
 ! [rejected]        featureB -> featureB (non-fast-forward)
error: failed to push some refs to 'https://github.com/x.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

为什么会发生这种情况

---

我们认为在

origin/develope

上重新设置

featureB

（现在合并后包含

featureB

）将使

featureB

为推送做好准备。但显然我们看到了一些错误。

解释发生了什么的最简单方法是查看回购历史。以下是合并前您的历史记录（节略版）：

*--*--*--* [develop, origin/develop]
          \
           *--*--* [featureA, origin/featureA]
                  \
                   A--B--C [featureB, origin/featureB]

合并和合并后：

*--*--*--*---------* [develop, origin/develop]
          \       /
           *--*--*
                  \
                   A--B--C [featureB, origin/featureB]

然后将

featureB

重新设置为

develope

：

*--*--*--*---------* [develop, origin/develop]
          \       / \
           *--*--*   A'--B'--C' [featureB]
                  \
                   A--B--C [origin/featureB]

这里，

A'

、

B'

和

C'

分别包含与

A

、

B

和

C

相同的更改，但它们不是相同的提交，因为

A'

具有不同的父提交

因此，在每次重基之后，必须强制推送重基分支：

git push --force-with-lease origin featureB

（使用租约强制执行

--force

可确保自上次获取后没有推送新的提交。虽然这里可能并不严格需要它，但最好养成在

--force

上使用该命令的习惯）

---

正如我在上一张图中看到的，任何时候分支（如

featureB

）及其远程跟踪分支（如

origin/featureB

）发散时，都必须强制推送。因此，您需要在对已推送到远程的分支重新设置基础时执行此操作。

针对开发分支“PRs it”。正文：“开发是一个默认分支”我不认为我混淆了推送、公关和合并。开发人员推送并创建拉请求（PRs），经理将其合并。我在更新后的文章中做了一些解释。希望这能让事情变得更清楚一点？有什么真正的理由重新调整这些分支机构的基础吗？或者，我也可以想象，无论合并还是重新基础，这些分支中的一个冲突都会表示冲突。哇！现在，当我运行gitk时，我发现这正是发生的事情。那么让我问你们，force with lease只是解决这种情况的一种方法，但我们的工作流程中有更好的git方法，还是我们通常应该使用它？换言之，您通常会以这种或其他方式介绍我们的工作流程吗？这会让您真正了解所发生的事情。非常感谢！