敏捷項目的Git分支策略

Question

我有一個位於Git Stash Repository中的項目。代碼將部署在四個環境中（Dev，Test，Stage和Prod）。我們遵循敏捷方法。因此，開發團隊適用於發佈活動和非發佈（未來發布）活動。我必須根據這個要求創建分支。以下是我的計劃。

三個穩定的分支：掌握，發佈和開發。

master是默認分支。發展將由主人創造。將從開發創建發佈

功能分支 - >它們將從開發創建。每個開發人員都有一個功能分支，他們在完成後將代碼合併到開發分支中。所以開發分支會發生開發環境部署。

如果需要更改測試環境，我們在這裏有兩種方法。一個是將開發分支與發佈分支合併（測試環境部署將從發佈分支發生）。我們無法實現這一點，因爲開發分支可能同時發佈版本和非版本更改。

另一種方法是將功能分支直接合併到發佈分支中。以便每個開發人員的更改都可以合併到發佈分支中。我不確定我是否可以實施這種方法。有人可以告訴我，如果這種方式可行嗎？有沒有其他辦法來處理這種情況。

分支：

主分支--->開發分支 - >發佈分支

開發分支---功能BRANCH1 |功能分支2 |特色店3

---

部署：

開發分支 - >開發部署

發佈分支進行 - >測試部署

主分行 - >舞臺和督促部署

我無法將開發分支合併到發佈分支中。由於開發分支也有一些非發佈變化。我只需要在發佈分支上發佈更改。可以將特徵分支直接合併到發佈分支中嗎？這裏最好的方法是什麼？

Answer 1

聽起來對我來說，你非常接近選擇Git Flow。事實上，如果我沒有弄錯，這已經是你從戰略的基礎，你描述。這很棒。

我聽說你主要關心的是，你想要一個非發佈的「開發」分支，有點像「只是嘗試的東西了，可能不會編譯」環境/分支。 Git流確實有利於生產的「流動」。即一旦任何東西都從其功能分支合併到分支中，它就已經安排在下一個（非緊急）版本中。

Git的流動對如何處理這個建議，是不合並任務/功能爲發展，直到它可能足夠準備進入下一個升級/ PROD釋放有可能是一些修正。在git流程中，您總是會合並非快速轉發（git merge --no-ff FEATURE_BRANCH_NAME），這樣如果您正在接近staging/prod-release，並且此功能無法做好準備，您可以反向合併（單一）merge-commit，從而將其從開發或版本-分支。

我懷疑一個較長的討論這件事，只是在球場，我看到2種可能的方式來滿足自己的想法：

1）有2個開發分支：一個用於開發，發展分支，這將很快在一些質量保證或其他方面進行分期和發佈。還有一個用於實驗性的東西，它將進入開發/測試環境（例如通過持續部署）。我們稱之爲長期發展（這是一個不好和太長的名字，所以做一個更好的，或者你的團隊會恨你:)）。

思考：

• 發展部門要經常被合併到長期-發展分支，始終保持更新。
• 您可能需要2個開發環境進行測試，每個分支1個。
• 危險：從建立長期，開發是（也許是錯）分支機構合併成發展可能會拖更不能準備的東西到發展分支。解決方案可能是1）合併功能分支爲非fastforward到長期開發和2）櫻桃挑選合併此提交到開發。但是這很容易出錯，而且很複雜，而且一個錯誤的合併可能會使整個分支發生故障，污染它們，而沒有準備好進行分段/生產。

2）剛剛1 develop分支（如你建議），並從主

創建發佈分支，這可能是迄今爲止最簡單的方法。它需要每個開發人員多花點功夫，但不易出錯。

程序是：

• 在衝刺/開發週期的每一個開始，版本管理器創建的下一個版本分支基於斷主。例如。 release-sprint-42其中，創建時，等於主人分支。
• 開發人員用開發基地創建功能分支開發。他們將功能分支合併到開發一旦準備好進行測試，et.c.像你目前的建議。
• 如果特徵是「正確」和工作，合併提交一個從合併功能分支到發展創建的櫻桃採摘與-m選項爲發佈衝刺-42，例如git cherry-pick -m 1 COMMIT_HASH。在這裏，瞭解你選擇的父母是非常重要的（在我的例子中爲父母1.開發者應該閱讀並理解http://git-scm.com/docs/git-cherry-pick）。

思考：

• 危險可能是，在工作的一個特點開發分支可能無法在發佈，衝刺42分公司工作，因爲缺少的依賴關係。感謝上帝，這就是爲什麼我們有階段環境和內部最後期限:)
• 櫻桃採摘不是最容易做的事情。但絕對是嘗試避免通過合併將不需要的代碼拖入錯誤的分支的最佳方式。

四捨五入

哪一個是最好的選擇適合你，取決於你是如何發展。如果你有2首曲目，比如「每日支持東西」和「我計劃於今年12月發行的大特色」，你可能會選擇2個分支。如果長期發展不是1而是幾件事情和一個持續的事情（即如果你通常有很多任務，跨越多個衝刺/週期），我會選擇2.

理想情況下但是，我會默認推薦一種策略，在這種策略中，東西被分解成足夠小的碎片並且衝刺足夠大，通常可以在1個衝刺內完成任務/特徵（即合併和部署！）。但是，從經驗，我知道，那一廂情願罕可以實現:)

1兩最後一件事：我真的真的真的鼓勵你沒有1個發佈分支（永久），而是要創造一個新的版本分支對於每個sprint/cycle，像release-sprint-42,release-sprint-43，et.c. （不管你是以理想的git流程開發分支還是在第二種情況下關閉master分支，我建議）。永久發佈 - 我的經驗常常導致分支丟失，合併問題和其他不良情況。除此之外，主人和發展應該是永久分支機構。

期待這次討論:)