防止 Master Branch 领先于 dev

Question

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

起初我们的工作流程：

master branch - 始终干净且可用于部署
development branch - 收集新功能/错误修复（如果有）审核并批准
feature branch - 一个只有一项功能需要更改（它已从 development branch 分支出来）

每个成功的拉取请求（功能 > 开发）都会创建一个 merge-commit，这很好。

但是每个部署（开发 > 主控）也会创建一个 merge-commit，它只存在于主控中。所以发生的情况是，在 20 次部署之后，主分支比开发分支提前 20 次提交。

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

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

Answer 1

这就是我们的做法：当您认为您的功能已准备就绪 ("code drop") 时，从 development 分支一个 release 分支。运行在那里进行昂贵的测试并修复错误，然后将 release 合并到 master，并将 master 合并回 development。再次开始一个新的 release 分支。

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

Answer 2

我们有 3 个基础分支 develop、staging 和 master。无论我们构建什么新功能，我们都会在 feature/branch 中保存并在开发中拉取更改。由于此功能需要测试，因此将在 Staging 分支中再次拉取。在从测试人员处退出后，我们将其推送到 master 分支。与您的工作流程相比，我们对 master 分支的提交较少，但如果您对 pre-existing 代码进行了任何更改，合并冲突仍将存在。

Answer 3

正如您在 the presentation of GitFlow 中看到的那样，master 是一个始终是合并目标的分支，而不是源。因此，正如您正确观察到的那样， master 分支将包含其他分支没有的合并提交。那一点问题都没有，顶多是个表面问题。

你为什么生气？如果你坚持流程，你将有这些提交，但为什么还要关心它们呢？它们不会以任何方式影响工作流程。

Answer 4

您要求的是 "fast forward" 合并。既然你提到了 pull-requests，我假设你正在使用一些东西来为你管理你的分支（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

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

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

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

备注：

如果您这样做，您将无法查看 development 何时合并到 master。这可能不是问题（或者您可以通过其他方式解决这个问题，例如使用标签）。
如果您在 master 上确实有唯一的提交并且 fast-forward 是不可能的，这仍然会创建一个 merge-commit。但是，如果 fast-forward 不可能（在 master 中的唯一提交或已经 up-to-date），您可以使用标志 --ff-only 来出错。

防止 Master Branch 领先于 dev

Prevent Master Branch from being ahead of dev

git

merge

branch

rebase

git-workflow