防止 Master Branch 领先于 dev

Question

我们有一个非常标准的 git 工作流程，但我对一件事感到恼火：master 领先于开发，因为每次部署我们都会创建一个从 dev 到 master 的合并提交。

首先我们的工作流程：

• master branch - 始终干净且可用于部署
• development branch - 如果经过审查和批准，收集新功能/错误修复
• feature branch- 一个只需要更改一个功能的新分支（它被分支了development branch）

每个成功的拉取请求（功能 > 开发）都会创建一个合并提交，这很好。

但是每个部署（development > master）也会创建一个仅存在于 master 中的合并提交。因此，在 20 次部署之后，主分支比开发分支提前 20 次提交。

你如何处理这种行为？您是否不时合并 master > dev （实际上除了创建无用的合并提交之外什么都不做）？

rebase development-branch 似乎不是一种选择，因为那样每个开发人员都会丢失跟踪的远程分支。

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

但是，如果您想避免合并提交，您确实希望快进分支：

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

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

笔记：

1. 如果这样做，您将无法查看何时development合并到master. 这可能不是问题（或者您可能正在以另一种方式解决这个问题，例如使用标签）。
2. 如果您确实有唯一的提交master并且无法进行快进，这仍然会创建合并提交。但是，如果无法--ff-only进行快进（独特的提交master或已经是最新的），您可以使用该标志来出错。

Answer 2

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

你为什么对此感到恼火？如果你坚持流程，你就会有这些提交，但为什么还要关心它们呢？它们不会以任何方式影响工作流程。