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个项目？
这样感觉很奇怪，不优雅。请教大家有没有什么好办法。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
ただ
tag:v14.04拉一个分支叫branch:14.04.1-dev，在里面进行开发，稳定以后打上tag:v14.04.1に従ってください、「ブランチ => 開発 => マージ」に固執しないでください、マージする必要がない場合はマージしません、特に複数のバージョンを同時に維持する場合はまったく問題ありません、Merge の代わりにチェリーピックが標準ですただし、git master は少し複雑で、プロジェクトによって戦略が異なります。master は安定版を意味し、新しいバージョンはブランチ内にあります。逆に、マスターは開発を意味し、安定版はブランチ内にあります。一部のマスターはリリースを意味します。これは、「オンライン展開との一貫性を維持するコード」を意味します。 したがって、master を直接使用するのではなく、より明確なブランチ名を使用する方が良い戦略かもしれないと思います。
リリースには対応するリリース ブランチがあります
あなたが説明したシナリオでは、異なるブランチまたは異なるプロジェクトにある異なるバージョンは基本的に同じであると思います。異なるブランチは基本的にマージされないためです（ブランチの名前についてあまり心配する必要はありません）。ですので、異なるバージョンに変更を適用する必要がある場合は、以下の方法が考えられると思います。
git サブモジュール管理モジュールを使用して、変更を行うときにサブモジュールに対応するハッシュを直接変更できます。-
複数支店管理を利用する場合-
マルチプロジェクト管理を使用する場合、git archive を使用して関連ファイルを取得できます-
もちろん、どの方法にも落とし穴があることは間違いありません。git Cherry-pick を使用してコミットをマージする-
git checkout を使用して個々のファイルを直接取得します-
こんにちは。この種の複雑なバージョンのシナリオは Gitflow に適しています。Gitflow に直接アクセスして確認できます。リンクは次のとおりです: http://nvie.com/posts/a- success-git-branching-model/