2012-08-04 15 views
3

你如何跟蹤你的發佈?追蹤發佈,分支機構或標籤?

目前,我們有2個主要分支

  • 開發
  • 發佈

持續發展的幾個人做總是發生在dev。一旦完成了足夠數量的更改,代碼就會合併到release中,由其構建並在其中進行標記。然後代碼被部署。

問題:這工作正常,但通常情況下,新的錯誤發揮作用,目前在開發分支中處理,有..移動(有時是很多)。一旦問題得到解決,出現給客戶的新版本通常包含修補程序和一些新功能。

我想的過程中更改爲以下:

  • 當前< - 目前的開發流,最新和最偉大,尚未部署
  • 督促< - 目前在督促,從合併dev/1.0.2
  • dev/1.0.0 < - 一段時間內建立並交付給prod
  • dev/1.0.1 < - 錯誤修復到以前的版本,將生成和發送到產品
  • dev/1.0.2 < - 錯誤修復到以前的版本,將被構建並交付給產品。 當前在產品

您認爲如何?這種趨勢是否會發揮作用並長期持續?我們每年發行約15次,每次發行至少有2-3次事故發生後需要修復,所以粗略地說,我們每年會有75個分支(這是很多的,但我想在一段時間後,他們可以被刪除)

+1

您想修復'release'分支上的錯誤,並且能夠將它們部署到生產環境中,而無需從'dev'分支引入正在進行的工作?難道你不能直接從'release'分支,修正這個bug,並且在'release'和'dev'中合併這個分支的變更? – lanzz 2012-08-04 20:59:16

回答

3

如果有幾個人從事新功能(和現有功能的改進),他們都使用開發分支來提交他們的代碼,那麼您永遠無法確定開發分支是否穩定。如果開發人員使用功能分支來構建新功能,並且只在功能完成時將這些功能合併到開發分支中,則開發分支始終應該是穩定的。 (然後功能分支也可以刪除。)

我喜歡git flow的解決方案。你有一個主(生產)分支和一個開發分支。還有一些功能分支,您可以在這些分支上使用新功能和修補程序分支來處理需要在生產中進行修復並且不能等到下一個發行版的事情。