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

这将是小说长度,所以我道歉。我提交的简短回答是,git流发布的完成将导致 develop 承诺 向前地 属于 master 基于git流起始器 Vincent Driessen 实现了他自己 git-flow scripts .

什么。。。git流 脚本 ?

我不确定你在 git-flow 如果我说的是显而易见的,请原谅。这个 git流 spec有一组脚本来简化它的使用。 Git流脚本随Git for Windows一起提供 我假设你是根据你的TFS参考使用的。

最新“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”命令将 整齐
   • 合并分支 版本/v2.1.0 分支 主人
   • 为版本v2.1.0创建带注释的标记
   • 合并分支 主人 进入之内 发展 确保发布中的所有提交 branch重新进入下一个版本的开发。

但如果我用的是TFS公关呢?

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

在我的商店里,我们也使用PRs,但是我使用 $git流发布完成-k ,然后按 主人 和 发展 树枝。TFS认识到发布分支已经合并,并将为您提供“关闭”而不是“完成”PR的选项,如下所示。

我从来没有做过你描述的额外的合并(或是加入过这样的团队)。我猜你 能够 如果你真的想开发的话,就合并master来开发,而不是合并release来开发——或者,至少,我想不出会出什么问题。。。但真的,怎么了 develop “落后”?这基本上是gitflow IMO的正常状态。

在您的场景中,development分支应该有一个commit behind master和一个commit ahead master(由于合并了PR YYY)。如果您从master创建另一个pull请求以进行开发,那么development分支将有另一个新提交(合并PR ZZZ),并且它将有一个commit ahead master(这是您想要的吗?).

您可以从master合并到development,而不是创建从release到development的Pull请求。