git 多版本並行發布時，該創建多個項目還是多個分支

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個項目？
這樣感覺很奇怪，不優雅。請教大家有沒有什么好辦法。

 

另外提醒你一件事情：master 不是什么特別的分支，只是恰好被選作默認分支的名稱而已。在 git 的模型中，所有分支都是平等的，沒有那種分支會比較特別一些。從這個角度來說，你對 master 現有的困惑同樣可以應用在其他任何一個分支上，如果你頭腦中明白了這個模型，現在看問題的角度是否不一樣了？

有些時候如果我們發現事情的發展已然導致當前的 master “廢了”，要合理恢復它很困難，那么更容易的手段是直接把更合適的分支更名為 master 讓它替代之前的那一個分支。聰明的你大概已經想到一些可能性了吧？在開發／工程的世界里，復雜的永遠不是工具而是人，思考陷入僵局的時候就得學會跳出“自己”。

我們再換一個角度，假定“同一個bug不一定能merge到多個版本分支里”這個命題是成立的，我們不得不把多個版本分拆成多個項目，那么問題能否解決呢？或者會不會變得好一些呢？顯然不可能。即使分拆為多個項目，多個版本需要共同修復同一個 bug 的現象始終存在。現在沒有了 Git 輔佐，請問你要怎么處理呢？一個一個手動修補嗎？

問題就在於你說的“不一定能merge到多個版本分支里”，你是怎么得出這個結論的呢？我能想象到由於管理和操作不當會引發各式各樣的麻煩，有個麻煩甚至相當頭疼，但終究都能找到合理的解決辦法。因此我只能認為發出此問者的 Git 技能不夠硬了——當然，Git 不是完美的，任何時候都算真理。

從tag:v14.04拉一個分支叫branch:14.04.1-dev，在里面進行開發，穩定以后打上tag:v14.04.1就好，不用拘泥於“分支=>開發=>合並”，不需要合並的時候就不合並，一點問題都不會有，尤其是多版本同時維護的時候，cherry-pick取代merge是常態

不過git的master確實有點混淆，不同的項目的策略不一樣，有的master是stable的含義，里面是穩定版本，新版本在分支里，有的反過來master是dev的含義，穩定版本在分支里。還有的master是release的含義，里面是“保持和線上部署一致的那份代碼”。 所以我覺得可能直接不用master，用更明確的分支名稱有可能是個更好的策略？

我認為你描述的場景下，不同的版本在不同的分支下或者不同的項目下基本是一樣的，因為不同分支之間基本不會合並了（分支叫什么名字可以不用太過在意）。那么在一個改動如果需要應用到不同版本時，我覺得可以考慮如下的方法：

• 可以采用git submodule管理模塊，改動時直接修改submodule對應的hash即可。
• 在采用多分支管理時
  
  
  • 用git cherry-pick的合並一個commit過來
  • 用git checkout直接把單獨的文件拿過來
• 在采用多項目管理時，可以用git archive把相關文件弄過來

• 我們開發的產品就是典型的多分支並行，已經持續運行2年+，沒有存在明顯的問題;大致介紹下幾個關鍵點，有更好的方案可以一起交流

  1. 每個發布的分支命名規范為版本號，類似 1.0 2.0 3.0
  2. 新功能開發從master拉分支開發，或者直接在 master上開發；測試通過后從master分支上拉新版本分支，如 4.0
  3. 版本分支上遇到bug需要修復時，需要合並后面的版本分支以及master分支
  4. 為了減少維護工作量,只維護最近的3個版本分支（低版本最終還是需要升級到新版本,只是存在時間差）