在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(-)
现在我对此有很多问题:
即使如此,实际上我还是希望我的开发分支具有一个明确指示该版本为开发版本的版本号(因为没有人在某个地方找到所生成的“ myproject-1.2.jar”文件时,应考虑运行该版本生产环境中的jar文件)。因此,从创建发行分支的那一刻起,我希望版本号反映“这是版本1.2.0”和“这是基于1.2的开发版本”。
[不幸的是,在创建发行分支时,每次我尝试合并来自发行分支的更改时,将版本号更改为“ 1.2”以及开发分支上的“ 1.2 + dev”之类的东西都会导致冲突。发展。 您对如何使用git进行这种版本控制有任何建议吗?
似乎以下工作流程实际上能够在git中实现所需的版本控制:
<last-release>+dev
。<next-release>
然后提交。releases/v<next-release>
来自开发。<next-release>+dev
然后提交。releases/v<next-release>
分支到master并标记它。这样,
因此我们遇到了同样的问题,并提出了三种可能的解决方案:
1。)创建发行分支并将版本在初始提交中进行修改时,然后将develop分支中的版本更改为下一个可能的版本,并将alpha
附加到该版本中,例如2.0.0-alpha
,以便我们知道这是将来可能的版本的预发行版(alpha表示可能合并了新功能)。如果下一个版本号最终与我们输入的版本号不同,则只需将其更改为正确的版本。
2。)开发分支的最后一个版本后面附加了+development
,因此很明显,这是从分支分支和/或从master部署的最新版本的开发版本。但是,我们发现这还不清楚,因为它可能给人留下印象,即它意味着该版本的开发版本……这是不正确的……因为它早于该版本!
3。)我们结合了这两种想法...我们在develop分支上修改了版本,但是我们根据分支名称动态地进行了修改......并且我们使用了更有意义的方式来表明它确实是开发版本,而不是在此阶段发布任何形式的内容,例如在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
所以您会获得基于最新发行版本的内部版本号。