Gitflow在发布后，develop分支落后于master分支

Question

我们在使用Gitflow进行git分支工作流（通过TFS）。 当发布成功时，我们会执行以下操作：

1. 从发布到主分支发起pull request
2. 从发布到develop分支发起pull request

步骤1会创建一个提交（合并PR XXX: 将发布合并到主分支）。

步骤2会创建一个提交（合并PR YYY: 将发布合并到develop分支）。

当我查看我们的分支时，它显示develop分支比主分支落后了一次提交。这是因为提交（合并PR: XXX）不在develop分支上。

正确的程序是简单地从主分支到develop分支创建另一个pull request（即使没有任何更改）吗？

我在标准的Gitflow模型中没有看到这个步骤。

- openshac

Answer 1

这将是一篇小说长度的文章，所以请见谅。我提交的简短答案是，根据Gitflow发起人Vincent Driessen实现自己的git-flow脚本，完成Gitflow发布应该导致develop在提交方面领先于master。

什么是git-flow脚本？

如果您对git-flow没有经验，请原谅我说了显而易见的话。git-flow规范有一组脚本，使其使用更加容易。Git flow脚本随Git for Windows一起提供，我假设您正在使用基于TFS的Git for Windows。

最近“v2.1.0”版本发布的结果

让我们通过Git Bash检查最近发布的历史记录。

$ git log --oneline --graph --decorate

这将产生

在上面的图片中，你会注意到：

1. 一个文件上传功能已经合并到develop分支中。此时，我想要发布产品。 2. 为了发布，我执行了命令$ git flow release start v2.1.0。 3. "git flow release start ..."命令自动创建了分支release/v2.1.0。这个分支只包含一个提交——版本号的增加。 4. 在这一点上，我已经测试过并且对发布结果满意，所以我使用$ git flow release finish -k来完成它。 5. "git flow release finish"命令将按顺序执行以下操作：

- 将分支release/v2.1.0合并到master分支。 - 为发布的版本v2.1.0创建一个带注释的标签。 - 将master分支合并到develop分支，以确保发布分支中的所有提交都回流到下一个版本的开发中。

但如果我正在使用TFS PR呢？

如果您在工作流程中使用TFS PRs，当您准备完成发布PR时，可能会看到类似于以下内容的信息。

在我的店铺中，我们也使用PR，但我使用$ git flow release finish -k本地合并，然后推送master和develop分支。 TFS会识别已经合并的发布分支，并给您提供“关闭”而不是“完成”PR的选项，如下所示。

- Mike Atkisson

---

这很有道理。谢谢你的解释。 - openshac

查看了链接的 git flow 脚本后，发现“将主分支合并到开发分支以确保发布分支中的所有提交”是错误的。它应该从发布分支合并到主分支和开发分支。所以，OP 是正确的，如果使用 git flow 脚本，则每次发布时主分支应该更加领先（dev 也是如此，但在下一个版本中，由于发布提交返回到主分支，这个问题会得到解决）。但我可能误读了这些脚本。我们的团队就是否在 master 到 develop 之间进行 --no-ff 和定期合并 master 到 develop 进行了辩论。 - Julien N

@JulienN：我还没有阅读Git Flow脚本，所以你可能是对的。但我可以告诉你，在我们的几个项目中都使用Git Flow，并且git flow release finish总是会产生我在第一张图片中发布的图形。请注意合并提交953492f（develop的顶端）有提交a14b2aa（master的顶端）作为其父级之一。 - Mike Atkisson

看起来你并没有使用Vincent Driessen的gitflow，而是它的分支gitflow-avh（请参见“为什么git-describe对我不起作用？”中的答案，描述了当前的实现以及被划掉的先前答案描述了原始行为）。 - CidTori

请查看我的回答获取更多信息。 - CidTori

Answer 2

我从未执行过你所描述的额外合并（或者在执行该操作的团队中）。我猜想，如果你真的想要这样做，你可以将主分支合并到开发分支而不是将发布分支合并到开发分支-或者至少，我想不出会出现什么问题...但实际上，develop 落后于其他分支有什么问题？在我的看法中，这基本上是 gitflow 中正常的状态。

- Mark Adelsberger

---

@openshac: 像你在问题中描述的那样，这正是原因所在... - Mark Adelsberger

我理解为什么会落后。但是，如果我有很多空的“合并”提交不在develop分支上，那么我就很难发现真正的更改，比如我需要合并到develop的热修复。如果开发人员没有注意到这一点，他们可能会创建一个已删除热修复的发布版本，并将其部署到生产环境中。 - openshac

@openshac - 如果我们正在讨论gitflow，那么在将hotfix合并到生产环境的同时，您需要将其合并到开放版本（如果没有开放版本，则合并到develop分支）。Gitflow使用分支和合并模式，以一种开发人员无法犯下您所描述的错误的方式（除非违反gitflow，并且不需要依赖“分支落后”计数的脆弱分析来避免它）。当然，gitflow并不是唯一的方法，但这就是您所问的。因此，我的问题是：在gitflow中，您认为develop落后是什么问题？ - Mark Adelsberger

@MarkAdelsberger 我同意这是gitflow的工作方式，但我们面临的问题是，将develop和master指向本质上逻辑相同的不同提交会令人困惑。这也可能导致CI流水线效率低下，因为它可能会导致额外的不必要的相同构建。是否有一种变体，可以将发布合并到主分支，然后再将主分支合并到开发分支？ - Phil

好的，OP提出了问题以澄清他们的困惑。对我来说也很令人困惑。他们在评论中也提出了一些很好的观点，解释了为什么他们感到困惑，我也是如此。如果您不同意我们的观点，那完全没问题。在这里辩论是否令人困惑是毫无意义的，因为这就是git-flow的工作方式。 - Phil

Answer 3

简而言之：您应该将发布标签（或主分支）合并到develop中，而不是将发布分支合并到develop中，与原始文章和大多数流行来源相反，因为存在一个与git describe有关的问题。

在原始文章和其作者Vincent Driessen aka nvie的git扩展中，命令如下：

git merge --no-ff $RELEASE_BRANCH

但是这种行为会导致 问题，在使用 git describe 命令时出现异常，因此提出了一个 PR，实现了以下命令：

git merge --no-ff $TAGNAME

（或者，如果没有标签，git merge --no-ff master）

Vincent Driessen 批准 了这个更改，但显然从未有时间正式宣布。

然后，由于其扩展缺乏积极支持，其分支gitflow-avh开始实现新行为，并成为新的标准（例如，在Windows和Ubuntu上默认设置）。

因此，总之，git flow release finish的行为应该是这样的：

git checkout master
git merge --no-ff $RELEASE_BRANCH
git tag -a $TAGNAME
git checkout develop
git merge --no-ff $TAGNAME
git branch -d $RELEASE_BRANCH

- CidTori

Answer 4

在您的情况下，develop分支应该比master分支落后一个提交，超过一个提交（由于合并的PR YYY），如果您从master到develop创建另一个pull request，develop分支将有另一个新的提交（合并的PR ZZZ），并且它将比master分支领先一个提交（这是你想要的吗？）。

与其从发布到开发创建Pull请求，不如直接从master到develop进行合并。

- Cece Dong - MSFT