Gitflow在发布后在master后面开发分支答案

【问题标题】：Gitflow develop branch behind master after a releaseGitflow在发布后在master后面开发分支
【发布时间】：2019-01-17 02:30:24
【问题描述】：

我们将 Gitflow 用于我们的 git 分支工作流程（通过 TFS）。发布成功后，我们执行以下操作

将请求从发布拉到主控
将请求从发布拉到开发

第 1 步创建一个提交（Merged PR XXX: Merge release to master）

第 2 步创建提交（Merged PR YYY：Merge release to develop）

当我查看我们的分支时，它说develop 是master 之后的一次提交。这是因为提交 (Merged PR: XXX) 不在开发中。

简单地从 master 创建另一个 pull request 来开发是否正确（即使 pull request 没有变化）？

我在标准 Gitflow model 上没有看到这个

【问题讨论】：

标签： git tfs git-branch git-flow

【解决方案1】：

我从来没有做过你描述的额外合并（或者在一个做过的团队中）。我猜你可以合并 master 来开发，而不是合并版本来开发，如果你真的想 - 或者，至少，我想不出任何会出错的地方......但真的， develop“落后”有什么问题？这基本上是 gitflow IMO 中的正常状态。

【讨论】：

@openshac : ?????由于您在问题中描述的确切原因...
我明白为什么它落后了。但是，如果我有很多未在开发中的空“合并”提交，这会让我更难发现真正的变化——例如我需要合并到开发中的修补程序。如果开发人员没有发现这一点，他们可以创建一个删除了修补程序的版本并将其部署到生产环境。
@openshac - 如果我们正在讨论 gitflow，那么在将修补程序合并到生产环境的同时，将其合并到开放版本（如果没有开放版本，则进行开发）。 Gitflow 使用分支和合并模式的方式使开发人员无法犯您所描述的错误，除了通过改变 gitflow 之外（并且不需要依赖对“分支落后”计数的脆弱分析来避免它）。当然 gitflow 不是 only 方式，但它是你所问的。所以我的问题是：在 gitflow 中，为什么你认为开发落后是一个问题？
@MarkAdelsberger 我同意这就是 gitflow 的工作方式，但我们遇到的问题是，让 development 和 master 指向在逻辑上基本相同的不同提交是令人困惑的。它还可能使 CI 管道效率低下，因为它可能会导致额外的不必要的相同构建。是否有一种变体将发布合并到主控，然后将主控合并到开发？
好吧，OP 提出了这个问题以消除他们的困惑。这也让我感到困惑。他们还在 cmets 中提出了一些关于他们为什么感到困惑的好观点，我也是。如果你不同意我们的观点，那完全没问题。无论如何，争论它是否令人困惑是徒劳的，这就是 git-flow 的工作原理。

【解决方案2】：

在您的场景中，开发分支应该在 master 之后有一个提交，在 master 之前有一个提交（由于 Merged PR YYY）。如果您从 master 创建另一个 pull request 来开发，develop 分支将有另一个新的提交（Merged PR ZZZ），并且它将在 master 之前有一个提交（这是您想要的吗？）。

您可以从 master 合并到 development，而不是创建从发布到开发的拉取请求。

【讨论】：

【解决方案3】：

这将是小说长度，所以我很抱歉。我提交的简短答案是 git flow 发布的完成应该导致 develop 成为 master 的提交 ahead 基于 git flow 发起者 Vincent Driessen 如何实现他自己的 @987654322 @。

什么... git-flow 脚本？

我不确定您对git-flow 的体验，如果我说的很明显，请原谅我。 git-flow 规范有一组脚本使其使用更容易。 Git 流脚本随 Git for Windows 提供开箱即用，我假设您正在使用基于您的 TFS 参考。

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

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

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

会产生的

在上图中你会注意到

将文件上传功能合并到开发中。在这一点上，我想发布产品。
要发布，我发$ git flow release start v2.1.0。
“git flow release start ...”命令自动创建分支 release/v2.1.0。这个分支只包含一个提交——版本号的增加。
此时我已经测试并且对发布感到满意，所以我完成它使用 $ git flow release finish -k
“git flow release finish”命令将按顺序
- 合并分支release/v2.1.0 到分支master
- 为版本 v2.1.0 创建一个带注释的标签
- 将分支master 合并到develop 以确保发布中的所有提交分支回到下一个版本的开发中。

但是如果我使用 TFS PR 会怎样？

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

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

【讨论】：

这是有道理的。感谢您的解释。
查看链接的 git flow 脚本，似乎Merge branch master into develop to ensure all commits in the release branch 是错误的。它从发布分支合并到 master & development。所以 OP 是对的，如果你使用 git flow 脚本，master 分支应该在每个版本中都更领先（dev 也是如此，但这在下一个版本中修复，因为版本提交返回到 master）。但我可能读错了脚本。我发现这个问题是因为我们的团队讨论过关于做一个--no-ff 并定期合并master 来开发或做--ff-only
@JulienN：我还没有阅读 Git Flow 脚本，所以你可能是对的。我可以告诉你，我们在我们商店的几个项目中使用了 Git Flow，git flow release finish 总是产生我在第一张图片中发布的图表。注意合并提交953492f（开发提示）有提交a14b2aa（大师提示）作为它的父母之一。
您似乎没有使用 Vincent Driessen 的 gitflow，而是它的 fork，gitflow-avh（请参阅“为什么 git-describe 对我不起作用？”的答案，描述了当前的实现，以及划掉的先前描述原始行为的答案）
更多信息请见my answer

【解决方案4】：

TL;DR：您应该将发布标签（或主标签）反向合并到开发中，而不是将发布分支反向合并到开发中，这与原始文章和大多数流行消息来源所说的相反，因为git describe的问题

在original article 和作者 Vincent Driessen aka nvie 的git extension 中，命令是：

git merge --no-ff $RELEASE_BRANCH

但是这种行为导致issue 和git describe，所以PR 是打开的，而是执行以下命令：

git merge --no-ff $TAGNAME

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

Vincent Driessen approved 这一变化，但显然从未有时间将其正式化。

然后，由于它的扩展缺乏积极的支持，它的 fork 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

【讨论】：