防止主分支超前于开发分支

Question

我们有一个相当标准的git工作流程，但我很烦恼一件事:主分支领先于开发分支，因为每次部署后，我们都会从开发分支创建一个合并提交到主分支。

首先我们的工作流程:

- `主分支` - 始终是干净的，并可供部署使用。 - `开发分支` - 如果已经审核和批准，则收集新功能/错误修复。 - `特性分支` - 仅具有一个特性所需的更改的新分支 (它是从开发分支分叉的)

每个成功的拉取请求(特性 > 开发)都会创建一个合并提交，这很好。

但是每次部署(开发 > 主)也会创建一个仅存在于主分支中的合并提交。所以问题在于，经过20次部署后，主分支比开发分支超前了20个提交。

你如何处理这种情况？您是否不时地将主分支>开发分支合并(实际上只创建一个无用的合并提交)？

重新设置开发分支似乎不是一个选择，因为那样每个开发人员都将失去跟踪的远程分支。

- denns

Answer 1

你所要求的是称为“快进合并”的操作。鉴于你提到了拉取请求，我假设你正在使用某个工具来管理你的分支（如GitHub、BitBucket等），因此实现你想要的操作的确切说明可能会有所不同。

---

在这种状态下：

master o-o-o-o
              \
development    o-o-o

您的软件在合并时很可能使用了--no-ff标志（这是标准行为，因为当将功能合并到development中时，您需要合并提交）。您可以通过以下命令行等效方式使用此标志：

git merge --no-ff development

master o-o-o-o-------o
              \     /
development    o-o-o

然而，如果你想避免合并提交（merge commit），你需要快进分支：

git merge --ff development（--ff 应该是不必要的，因为它是默认行为）

master/development o-o-o-o-o-o-o

---

注意事项：

1. 如果您这样做，您将失去查看 development 合并到 master 的能力。这可能不是一个问题（或者您可能会用标记等其他方式来解决此问题）。
2. 如果您在 master 上有独特的提交，并且无法进行快进，则仍将创建合并提交。但是，您可以使用 --ff-only 标志，如果无法进行快进（在 master 中有唯一提交或已经是最新状态），则会出错。

- Vlad274

---

太棒了，解释得非常好！非常感谢！ - denns

Answer 2

正如您在GitFlow的演示中所看到的，master分支始终是合并目标，而不是源。因此，正如您正确观察到的那样，master分支将包含没有其他分支的合并提交。这完全没有问题，最多只是一个表面问题。

为什么您会对此感到烦恼呢？如果您坚持遵循流程，您将拥有这些提交，但是为什么要关心它们呢？它们不会以任何方式影响工作流程。

- kowsky

---

烦人的是，Git总是显示dev分支为“20次提交落后，40次提交领先”，这并不是最直观的。如果我们在主分支中有一个热修复，你无法知道它是否缺少在dev分支中。 - denns

它在哪里显示出那种方式？我只知道从分支和其上游之间的比较中得到这种类型的消息，而您不会将主分支设置为本地开发的上游吧？至于热修复：谁将其合并到主分支，应立即将其挑选到开发分支。 - kowsky

Answer 3

这就是我们的做法：当您认为您的功能已准备好（“代码提交”）时，从 development 分支中分离一个 release 分支。在那里运行昂贵的测试并修复错误，然后将 release 合并到 master ，再将 master 合并回 development 。再次启动新的 release 分支。

您也可以在每次部署后将 master 合并回 development ，但如果 release 分支没有任何实际更改，那么这没有太多意义。

- choroba

Answer 4

我们有3个基本分支开发，暂存和主分支。无论我们构建什么新功能，我们都会保存在特性/分支中，并在开发中拉取更改。由于这个功能需要测试，所以它将再次被拉到暂存分支中。在得到测试人员的签署后，我们将其推送到主分支。与您的工作流程相比，我们对主分支的提交较少，但如果您对现有代码进行了任何更改，合并冲突仍将存在。

- Rachit07

---

你的回答应该针对问题：“你如何处理那种行为？”，而不是建议另一种工作流程，因为发帖者可能无法遵循。 - Michael Coxon