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

Extrayez une branche de tag:v14.04 et appelez-la branch:14.04.1-dev, et développez-y une fois qu'elle est stable, ajoutez simplement tag:v14.04.1 Vous n'êtes pas obligé de vous en tenir à "branche => développement => fusion". . Lorsque vous n'avez pas besoin de fusionner, juste sans fusion, il n'y aura aucun problème, surtout lorsque plusieurs versions sont maintenues en même temps, il est normal que le choix cerise remplace la fusion

.

Cependant, le git master est effectivement un peu déroutant. Différents projets ont des stratégies différentes. Certains master signifie stable, qui contient la version stable, et certains à l'inverse, master signifie dev, qui est la branche. version stable dans la branche. Certains master signifie release, ce qui signifie « le code qui reste cohérent avec le déploiement en ligne ». Je pense donc que ne pas utiliser master directement, mais utiliser un nom de branche plus spécifique pourrait être une meilleure stratégie ?

Answer 2

release a une branche de release correspondante

Answer 3

Je pense que dans le scénario que vous avez décrit, les différentes versions sous différentes branches ou différents projets sont fondamentalement les mêmes, car les différentes branches ne seront fondamentalement pas fusionnées (vous n'avez pas à trop vous soucier du nom de la branche). Ainsi, lorsqu'un changement doit être appliqué à différentes versions, je pense que les méthodes suivantes peuvent être envisagées :

• Vous pouvez utiliser le module de gestion des sous-modules git et modifier directement le hachage correspondant au sous-module lors des modifications.
• Lors de l'utilisation de la gestion multi-branches
  
  
  • Utilisez git Cherry-pick pour fusionner un commit
  • Utilisez git checkout pour importer directement des fichiers individuels
• Lorsque vous utilisez la gestion multi-projets, vous pouvez utiliser git archive pour récupérer les fichiers pertinents

Bien sûr, il ne fait aucun doute que chaque méthode comporte des pièges.

Answer 4

Bonjour, ce genre de scénario de version complexe est adapté à Gitflow Vous pouvez vous rendre directement sur Gitflow pour le savoir. Le lien est : http://nvie.com/posts/a-successful-git-branching-model/