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

Question

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

1. 将请求从发布拉取到主控
2. 将请求从发布拉到开发

第 1 步创建提交（合并 PR XXX：合并发布到 master）

第 2 步创建提交（合并 PR YYY：合并发布以开发）

当我查看我们的分支时，它说开发是 master 后面的一项提交。这是因为提交（合并 PR：XXX）不在开发中。

简单地从master创建另一个拉取请求以进行开发（即使拉取请求没有变化）的正确过程是正确的吗？

我在标准 Gitflow 模型上没有看到这一点

Answer 1

这将是小说长度，所以我很抱歉。我提交的简短答案是，Gitflow 版本的完成应该导致

develop

成为 master 的

ahead

，基于 Gitflow 创始人 Vincent Driessen 如何实现他自己的 git-flow 脚本。

什么... git-flow 脚本？

我不确定您对

git-flow

的体验，所以如果我说的是显而易见的事情，请原谅我。

git-flow

规范有一组脚本以使其使用更容易。 Git 流程脚本随 Windows 版 Git 一起提供，我假设您根据 TFS 参考使用它。

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

让我们通过 Git Bash 检查最近版本的历史记录

$ git log --oneline --graph --decorate 产生

在上图中，你会注意到

开发中合并了文件上传功能。 此时，我想要 发布产品。
为了发布，我发布了
2. $ git flow release start v2.1.0

   。

“git flow release start...”命令自动创建分支
3. release/v2.1.0

   。  该分支仅包含一次提交——版本号的增加。

此时，我已经测试并且对发布感到满意，所以我使用完成它
4. $ git flow release finish -k
“git flow release finish”命令将
5. 按顺序

将分支
• 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 的选项，如下所示。

Answer 2

我从来没有做过你描述的额外合并（或者加入过这样做的团队）。 我猜你

可以合并master来开发，而不是合并release来开发，如果你真的愿意的话——或者，至少，我想不出任何会出错的地方......但实际上，develop出了什么问题

 被“落后”？  在我看来，这基本上是 gitflow 中的正常情况。

Answer 3

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

的问题

在

原始文章以及作者 Vincent Driessen 又名 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

Answer 4

在您的场景中，开发分支应该在 master 后面有一个提交，并且在 master 之前有一个提交（由于 Merged PR YYY）。如果您从 master 创建另一个拉取请求以进行开发，则开发分支将有另一个新提交（合并 PR ZZZ），并且它将有一个提前提交 master （这是您想要的吗？）。

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