branch - git 多版本并行发布时，该创建多个项目还是多个分支

Question

git 做单版本在线的项目是很成熟的，流程很清晰，每个issue创建一个branch，然后合并到master，打tag即可。
比如web项目，发布了1.0.0，然后修bug发布1.0.1、 1.0.2，新功能1.1.0、 1.2.0，改版大功能2.0.0 。只有一个版本在维护，一般不会出现 1.0.0 和 2.0.0 同时都在发布新版的情况。
git简单流程：http://rogerdudler.github.io/git-guide/index.zh.html

复杂点的流程：http://jiongks.name/blog/a-successful-git-branching-model/

但多版本并行发布的时候怎么办？
以Ubuntu系统为例，14.04 、 14.10 、 15.04 同时存在，14.10发布后，14.04也在持续的发布新版，比如14.04.1 、 14.04.2。

如果按照上面的git简单工作流程：
14.04在master里打tag发布了，下一个里程碑是14.10，很多人开发了很多分支，然后合并到master里，每天发布daily build版，看起来很美好。
突然，14.04有个紧急bug要修复，不可能等几个月等到14.10发布时带着一起修复，需要发布14.04.1那怎么办？从哪里checkout 14.04的代码？即使从tag里checkout下来了，修复完毕，合并到哪里？只能合并到master，但master是14.10，不能发布啊。

如果按照git复杂流程：
14.04在master里打tag发布了，下一个里程碑是14.10，很多人开发了很多分支，然后合并到develop分支里，每天发布daily build版。
突然，14.04有个紧急bug要修复，从master拉一个分支叫做hotfix-xxx，修复完毕，合并到master，打tag，发布14.04.1 。也合并到develop。
当14.10开发完毕，打算发布时，从develop拉一个分支叫做release-14.10，收尾完毕，把release-14.10合并到master，打个tag，发布了。也合并到develop，看起来很美好。
突然，14.04又有个紧急bug要修复，需要发布14.04.2怎么办？从哪里checkout 14.04.1的代码？即使从tag里checkout下来了，修复完毕，合并到哪里？只能合并到master，但master是14.10啊。

难道是每个版本一个项目？ 比如 14.04 、14.10 、15.04 是3个项目？
这样感觉很奇怪，不优雅。请教大家有没有什么好办法。

Answer 1

Just follow tag:v14.04拉一个分支叫branch:14.04.1-dev，在里面进行开发，稳定以后打上tag:v14.04.1, don't stick to "branch => development => merge", don't merge when there is no need to merge, there will be no problem at all, especially when multiple versions are maintained at the same time, cherry-pick replaces Merge is the norm

However, the master of git is indeed a bit confusing. Different projects have different strategies. Some master means stable, which contains the stable version, and the new version is in the branch. Some conversely, master means dev, and the stable version is in the branch. inside. Some master means release, which means "the code that remains consistent with the online deployment". So I think it might be a better strategy to not use master directly, but to use a clearer branch name.

Answer 2

release has a corresponding release branch

Answer 3

I think in the scenario you described, different versions under different branches or different projects are basically the same, because different branches will basically not be merged (you don’t have to worry too much about the names of the branches). So when a change needs to be applied to different versions, I think the following methods can be considered:

• You can use the git submodule management module and directly modify the hash corresponding to the submodule when making changes.
• When using multi-branch management
  
  
  • Use git cherry-pick to merge a commit
  • Use git checkout to directly fetch individual files
• When using multi-project management, you can use git archive to get related files

Of course, there is no doubt that every method has pitfalls.

Answer 4

Hello, this kind of complex version scenario is suitable for Gitflow. You can go directly to Gitflow to find out. The link is: http://nvie.com/posts/a-successful-git-branching-model/