发布后 Gitflow 在 master 后面开发分支
Gitflow develop branch behind master after a release
我们在 git 分支工作流中使用 Gitflow（通过 TFS）。
发布成功后，我们将执行以下操作
- 从发布拉取请求到 master
- 从发布拉取请求到开发
第 1 步创建提交（Merged PR XXX：Merge release to master）
第 2 步创建提交（Merged PR YYY：Merge release to develop）
当我查看我们的分支时，它说 develop 是 master 之后的一个提交。这是因为提交（合并 PR：XXX）不在开发中。
从 master 简单地创建另一个 pull request 到 develop 的正确过程是正确的吗（即使 pull request 没有变化）？
我在标准中看不到这个 Gitflow model
我从来没有做过你描述的额外合并（或者在做过的团队中）。我猜你 可以 合并 master 到 develop 而不是合并 release 到 develop 如果你真的想要 - 或者，至少，我想不出有什么会出错的......但实际上，develop 变成 "behind" 有什么问题？这基本上是 gitflow IMO 中的正常状态。
在您的场景中，develop 分支应该在 master 之后有一个提交，在 master 之前有一个提交（由于 Merged PR YYY）。如果您从 master 创建另一个 pull request 到 develop，develop 分支将有另一个新提交（Merged PR ZZZ）并且它将有一个提前提交 master（是您想要的吗？）。
与其创建从发布到开发的拉取请求，不如从主合并到开发。
这将是小说长度，所以我很抱歉。我提交的简短回答是 git 流程发布的完成应该导致 develop 成为 ahead 的提交 master 基于如何git 流量发起者 Vincent Driessen implemented his own git-flow scripts。
什么...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 认识到发布分支已经被合并，并且会给你 "Close" 而不是 "Complete" PR 的选项，如下所示。
TL;DR：您应该将发布标签（或 master）反向合并到开发中，而不是将发布分支合并到开发中，这与原始文章和最流行的来源所说的相反，因为 git describe
有问题
在其作者 Vincent Driessen aka nvie 的 original article, and in the git extension 中，命令是：
git merge --no-ff $RELEASE_BRANCH
但此行为导致 issue with git describe, so a PR 被打开，改为执行以下命令：
git merge --no-ff $TAGNAME
（或者，如果他们没有标签，git merge --no-ff master）
Vincent Driessen approved 此更改，但显然没有时间将其正式化。
然后，由于它的扩展缺乏积极的支持，它的分支 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
我们在 git 分支工作流中使用 Gitflow（通过 TFS）。 发布成功后，我们将执行以下操作
- 从发布拉取请求到 master
- 从发布拉取请求到开发
第 1 步创建提交（Merged PR XXX：Merge release to master）
第 2 步创建提交（Merged PR YYY：Merge release to develop）
当我查看我们的分支时，它说 develop 是 master 之后的一个提交。这是因为提交（合并 PR：XXX）不在开发中。
从 master 简单地创建另一个 pull request 到 develop 的正确过程是正确的吗（即使 pull request 没有变化）？
我在标准中看不到这个 Gitflow model
我从来没有做过你描述的额外合并（或者在做过的团队中）。我猜你 可以 合并 master 到 develop 而不是合并 release 到 develop 如果你真的想要 - 或者，至少，我想不出有什么会出错的......但实际上，develop 变成 "behind" 有什么问题？这基本上是 gitflow IMO 中的正常状态。
在您的场景中，develop 分支应该在 master 之后有一个提交，在 master 之前有一个提交（由于 Merged PR YYY）。如果您从 master 创建另一个 pull request 到 develop，develop 分支将有另一个新提交（Merged PR ZZZ）并且它将有一个提前提交 master（是您想要的吗？）。
与其创建从发布到开发的拉取请求，不如从主合并到开发。
这将是小说长度，所以我很抱歉。我提交的简短回答是 git 流程发布的完成应该导致 develop 成为 ahead 的提交 master 基于如何git 流量发起者 Vincent Driessen implemented his own git-flow scripts。
什么...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 认识到发布分支已经被合并，并且会给你 "Close" 而不是 "Complete" PR 的选项，如下所示。
TL;DR：您应该将发布标签（或 master）反向合并到开发中，而不是将发布分支合并到开发中，这与原始文章和最流行的来源所说的相反，因为 git describe
在其作者 Vincent Driessen aka nvie 的 original article, and in the git extension 中，命令是：
git merge --no-ff $RELEASE_BRANCH
但此行为导致 issue with git describe, so a PR 被打开，改为执行以下命令：
git merge --no-ff $TAGNAME
（或者，如果他们没有标签，git merge --no-ff master）
Vincent Driessen approved 此更改，但显然没有时间将其正式化。
然后，由于它的扩展缺乏积极的支持，它的分支 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