开发和发布分支的版本控制（git-flow）答案

【问题标题】：Versioning on development and release branches (git-flow)开发和发布分支的版本控制（git-flow）
【发布时间】：2015-01-26 21:58:45
【问题描述】：

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 实现这种版本控制有什么建议吗？

【问题讨论】：

标签： git branch versioning release-management

【解决方案1】：

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

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

这样，

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

【讨论】：

【解决方案2】：

所以我们也遇到了同样的问题，想出了三种可能的解决方案：

1.) 当我们创建发布分支并在发布的初始提交中增加版本时，我们将开发分支中的版本更改为下一个可能的版本，并将alpha 附加到版本例如2.0.0-alpha 这样我们就知道这是未来可能版本的预发布（alpha 意味着新功能可能会被合并）。如果下一个版本号最终与我们输入的不同，那么我们只需将其更改为正确的版本即可。

2.) 开发分支已将 +development 附加到最后一个版本，因此很明显它是从分支分支和/或从 master 部署的任何最后一个版本的开发版本。但是我们发现这并不清楚，因为它可能给人的印象是该版本的开发版本......这不是真的......因为它领先于那个版本！

3.) 我们结合了这两种想法...我们在开发分支上修改了版本，但我们根据分支名称动态地进行...并且我们使用了更有意义的东西来表明它确实是一个开发版本并且在这个阶段不是任何形式的发布......例如在 Rails 中：

major = 1
minor = 0
patch = 0

version = [major, minor, patch].compact.join('.')

# only release and master branch have a version
# bugfix/hotfix/feature branches are NOT releases and therefore don't have a version!
branch = `git rev-parse --abbrev-ref HEAD`
release = branch.match? /release|master/

VERSION = if release
            version
          else
            "X.X.x-#{branch} (based on: #{version})"
          end

例如，我们部署了一个功能分支进行测试，VERSION 是：

X.X.X-feature/rest-api (based on: 1.0.0)

或者如果您不想使用分支名称...

你可以这样做：

VERSION = if release
            version
          else
            commits = `git rev-list --all --count`
            "rev #{commits} (based on: #{version})"
          end

因此，您会根据最后一个发布版本获得一种内部版本号。

【讨论】：