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

Question

关于 http://nvie.com/posts/a-successful-git-branching-model/它说:

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

$ 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(-)

现在我有很多问题:

• 开发分支仍然是 1.1.5；这个什么时候更新？开发分支在特定时刻的版本号“落后于”发布分支是否有意义？
• 假设我在创建发布分支之前增加了我的版本号。如果我这样做，我在 dev 和 release 分支上有相同的版本号，直到下一个版本，我认为这更有意义。 创建分支后 版本号增加的原因是什么？

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

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

Answer 1

看起来下面的工作流程实际上能够在git中实现所需的版本控制:

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

这样，

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