新精益團隊的Git分支策略

我們有一個網絡應用程序，我們有幾個企業客戶。我們最近決定將其作爲SaaS應用程序提供，並遵循精益方法（與我們的公司產品並行）。這意味着我們在實驗中可能無法投入生產。新精益團隊的Git分支策略

之前，我們去了精益我們很高興與下面的分支策略（我相信這是非常標準）：

主 - 總是穩定
開發 - 經常不穩定（功能分支切斷開發新功能到進入下一個主要版本）
major_release_x - 生活（切斷主後開發已合併成高手，這就是bug修復發生，並且合併到主和DEV）

現在我們有除了上述以下，它的工作不那麼好：

lean_release_branch - 生活（切斷major_release_x幷包含實驗）
experiment_x - 切斷major_release_x（這是我們破解功能一起，則m二哥成lean_release_branch）

我們的情景，現在是我們需要釋放快，往往作爲精益方法使然，而當我們的東西任意獲得堅實的反饋，那麼我們就需要productionize它並儘快釋放盡可能（關閉lean_release_branch）。

的問題是，我們不能創建一個特性分支關閉開發的（因爲它是最有可能是不穩定的），我們不能有兩個原因創建一個特性分支關閉lean_release_branch的：

已經通過實驗代碼污染使這一變化/功能將無法做它的方式回到主
的lean_release_branch總是需要準備發佈，所以我們不能忙做如果存在需要修復和發佈的關鍵問題，則可以對其進行測試並進行修復。

有人知道我們的設置有更好的策略嗎？

來源

2013-06-27 Markus Coetzee

在第二個最後一段中，你的意思是說，在對某個實驗的良好反饋後，重做功能必須成爲精益釋放的一部分？它何時成爲主要版本的一部分？ –

@NieldeWet我所指的「堅實的反饋」應該與實驗無關。因此，我們需要立即製作並儘快從lean_release_branch發佈，然後它需要找到進入未來主要發行版的路徑。 –

我剛剛從TFS更改爲GIT，我遵循的模型基於此post。

關於你的實驗，它只是「精選分支」，不會讓它回到開發（合併到開發）。

來源

2013-06-28 00:11:08 nozari

可能對nvie工作流程有一些不同的看法：https：//speakerdeck.com/ewoodh2o/a-sane-git-workflow – Zavael

因爲一切都在major_release_x已經在開發（因爲開發併入主上一個主要發行前）的productionised功能（以下成功的實驗），可以在一個特性分支進行關閉major_release_x，稱之爲production_feature_y，然後合併成兩個開發，成爲下一個主要版本，並lean_release_branch。

通過這種方式，您的精益版本中可以使用新的生產特性，並將在下一個主要版本中發佈，精益分支永遠不需要再次合併。在功能

而且客戶的反饋可以production_feature_y實現，並且合併到開發和lean_release_branch一次。

Bug修復可以以同樣的方式來處理，在分支完成關閉major_release_x合併爲兩個major_release_x和lean_release_branch。

來源

2013-06-28 08:46:57

這實際上是我們如何生成了幾條反饋，但它不太適合它違反了第一點。 2：「lean_release_branch總是需要準備好發佈，所以如果需要修復和發佈關鍵問題，我們就不能忙於測試和修復（在合併更改/功能之後）」 –

好的，但是如果你正在自己的分支上進行生產功能，當它合併的時候，它應該是生產準備就緒並準備好發佈了嗎？ –

它首先必須發佈到測試服務器，經過代碼審查並在其功能分支上進行開發人員測試後，因此它需要進入具有構建作業的分支（但不是lean_release_branch，因爲它需要100％穩定）。 –

除了GitFlow nozari提到，還有GitHub Flow。我工作的地方以此爲基礎（主人總是穩定，在特色分支中發展，在合併之前請求評論）。我們不太經常部署GitHub，因此我們使用annotated tags跟蹤發佈和輕量級標籤，指向現在正在進行的任何提交。這是由capistrano-deploytags Ruby寶石管理的。

除非我錯誤地閱讀了您的問題，否則您可以在所有這些分支中使用此策略實現相同的複雜性。

來源

2013-06-28 10:04:17 Rafe

新精益團隊的Git分支策略

回答

相關問題