我應該在Git Flow中擁有長期的功能分支嗎？

Question

我正在團隊中使用Git Flow。我們都分支開發功能，並在代碼審查後重新合併。它對我們來說效果很好，但是現在我們有一個功能可以讓開發人員在一個月內完成。這段時間我們將有幾個版本。

來推動這幾個問題：

• 我們應該如何處理呢？
• 我們應該這樣處理嗎？
• 或者我們應該把這個功能切成更小的合併請求嗎？
• 如果我們把它砍掉，它是一個公共項目，我們如何確保這個功能的各個部分不影響正在發佈的版本？
• 正在合併發展成這個長期功能分支真的那麼糟糕？我的同事擔心它是反模式。
• 如果我們不一致地將開發合併回這個長期特徵中，那麼當特徵最終完成時不會有不好的後果嗎？

Answer 1

我無法從強烈的立場回答您的問題，但我可以指出您有關gitflow的blog post。

注意靠近頂部的圖像。它記錄了將來發布的功能（因此，這是一個長期功能）。

這使我相信這是適當的行爲，當情況需要時這是必要的。

Answer 2

在以前的公司中，至少有1/3的分支機構「長時間運行」至少2周或更長時間（正在開發一個月的分支機構很常見）。我們也使用gitflow模式。基本上我們會在分支上工作，並定期將分支開發和重新設計。這與將開發合併到我認爲被認爲是反模式的特性分支非常相似。

真正的關鍵是維護分支，而不是讓它落後太多。陳舊的分支有時候是最痛苦的嘗試和更新。考慮到你是否有時間跟上其他優先事項的分支需要考慮進去。

測試/環境設置也很重要。有一個長期運行的分支意味着它最有可能是一個重要的功能/變化，所以它可能也會被測試。如果您的QA'ers（無論是團隊還是您自己和其他開發人員）可以在分支環境中準備好接近準備時測試分支，那麼這對您有幫助。

Answer 3

這在我的工作場所也很常見。我們按照每週發佈計劃工作，因此每個星期三的新功能都會達到產量。正因爲如此，幾乎所有的功能都是半成品，而不是生產準備就緒。

所以，在關於長期分支，這裏就是爲我們最好的工作：

• 分公司關閉該功能正常（feature-1）
• 隨着feature-1支切斷，工作的開始正常。
• 如果功能足夠大，則分解爲更小的子任務。 （例如，創建服務;將服務實現到控制器中;等等）
• 然後爲子功能（sub-task-1，sub-task-2等）的每個增量更新分支feature-1，當子任務完成時合併回feature-1。 （這允許feature-1只包含全功能的代碼）
• 雖然在feature-1和子任務進度的發展，很重要的一點是永久居民被合併到develop，你變基feature-1分支。如果不這樣做，通常會在準備特徵PR時導致大幅變形。

你可能注意到了，沒有從你的正常工作流程多引水，它更多的紀律的問題，以確保墊底被經常做的和半生不熟的代碼不使其向develop。

希望這會有所幫助。