开发和发布分支的版本控制 (git-flow)

Question

在http://nvie.com/posts/a-successful-git-branching-model/ 上，它说：

发布分支是从开发分支创建的。例如，假设版本 1.1.5 是当前的生产版本，我们即将发布一个大版本。开发状态已为“下一个版本”做好准备，我们决定这将成为 1.2 版（而不是 1.1.6 或 2.0）。所以我们分支并给发布分支一个反映新版本号的名称：

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

现在我有很多问题：

• develop 分支仍然在 1.1.5；这个什么时候更新？在某个时刻，就版本号而言，开发分支“落后”于发布分支是否有意义？
• 所以说我在创建发布分支之前增加了我的版本号。如果我这样做，在下一个版本之前，我在 dev 和 release 分支上有相同的版本号，我认为这更有意义。创建分支后出现版本号颠簸的原因是什么？

即便如此，实际上我希望我的开发分支有一个版本号，清楚地表明这是一个开发版本（因为没有人在某处找到生成的“myproject-1.2.jar”文件的人应该考虑一下运行这个 jar 文件在生产环境中）。因此，从我创建发布分支的那一刻起，我希望版本号能够反映“这是 1.2.0 版”和“这是基于 1.2 的开发版”。

不幸的是，在创建发布分支时，将版本号更改为“1.2”以及开发分支上的“1.2+dev”之类的内容将导致每次我尝试将发布分支中的更改合并回开发时发生冲突. 您对如何使用 git 进行这种版本控制有什么建议吗？

Answer 1

似乎以下工作流程实际上能够在 git 中实现所需的版本控制：

• 开发分支上的版本是 <last-release>+dev.
• 从开发分支发布新版本时：
  • 将文件中的版本号更改为 <next-release> 并提交。
  • releases/v<next-release> 从开发创建分支 。
  • 在开发时，将文件中的版本号更改为 <next-release>+dev 并提交。
  • 发布完成后，将releases/v<next-release> 分支合并 到 master 并标记它。

这边走，

• 很容易知道当前开发代码基于哪个发布版本，
• 在基于开发的分支上创建的 jar 文件很容易被检测为开发版本，
• 而发布分支上的提交仍然可以合并回开发分支。