2010-10-29 102 views
3

我用的是墊底的特性分支流程http://www.golden-gryphon.com/software/misc/packaging.html的Git - 上游+功能+分支發佈分支

但由於本地測試者和管理員不喜歡一次性發布分支,我需要移動與穩定分支的worklow 。

唯一可以接受的是合併工作流程。現在的問題是我不知道如何在這個工作流中使用相關的功能分支。重新綁定時,這很簡單,每個補丁都簡單地重新設置了所有依賴此分支的功能分支,並且一切恢復正常。通過合併工作流程,我無法重設我的功能分支,但合併似乎對此有點瘋狂。

有沒有更好的方法?

+0

鏈接是死的,但它是在http://web.archive.org/web /20111230235724/http://www.golden-gryphon.com/software/misc/packaging.html – 2013-05-28 07:34:02

回答

5

與幾個長期的特點,模型可能是這樣的:

 o-----o bugfix 
    /  \ 
o--o--o------o------o develop branch 
     \  \  \ 
     o-o----o---o--o long-term feature 1 
      \ \ \ \ 
      o--o-o-o-o--o--o feature 2 

基本上,你有一個發展分支,合併錯誤修正你的開發分支。長期功能分支是開發分支的基礎,您可以通過合併來自該開發分支的新更改來更新它。

同樣,基於特徵1,你有一個特徵分支2,並且你通過合併新東西新特徵1分支來更新它。

當功能1完成後,你把它合併到開發和更新功能2從開發分支:

 o-----o bugfix 
    /  \ 
o--o--o------o------o---o---o develop branch w/ feature 1 
     \  \  \/ \ 
     o-o----o---o--o  \ 
      \ \ \ \  \ 
      o--o-o-o-o--o--o--o-o feature 2 
+0

看起來有點類似我現在所在的地方。任何提示用於管理功能分支之間的依賴關係?我有5個功能分支全部用作2個其他功能分支的基礎。 – 2010-11-02 15:14:22

+0

我想沒有多少人有很多分支機構不能簡單地手工同步它們。但我想你可以編寫一些腳本來完成所有的同步,並檢測可能的衝突和破壞。最困難的是,你必須爲每個補丁選擇正確的分支(例如,如果你需要一些通用機制來實現「特性2」,並且你將需要它來實現其他功能,那麼最好是在一個補丁中實現它祖先的分支) – che 2010-11-02 15:23:59

+0

@Let_Me_Be這取決於你的回購(和一般的軟件)是怎樣的。從你的評論我猜它是核心 - > {feature1 ... 5} - > {otherfeatures1 + 2} [我真的很討厭不能把acii-art置於評論中]。如果您有像開發分支這樣的中央庫,並且您的功能分支僅包含新功能(=沒有核心開發),並且這些功能分支不會彼此共享補丁,那麼合併工作流程很簡單。 – Rudi 2010-11-03 07:02:23

2

合併和rebase工作流的主要區別在於合併在rebase工作流中是不可見的,但它們仍然存在(您可以在rebase之後的reflog中看到它們)。甚至還有更多的使用rebase,因爲對於每一個要重新分支的新變更集都會執行它自己的合併,而在純合併工作流程中,只有兩個分支頭之間合併完成。

一個典型的合併工作流程是這樣的:

   o-o-o--------------o   Release1+bugfixes 
      / \    \ 
o-----o----o--o-o--o---o----o-o-o-o-o--o develop 
     \ /    \ /
     o-o-o Feature 1  o---o Feature 2 

短期功能被開發的發展,長期特徵獲得自己的分支機構。功能分支被合併回開發。對於每個版本,都是從開發中創建一個分支,並在發生該bug的發佈分支上創建錯誤修正。當一個錯誤修復完成後,它會被合併回開發。

更好的解釋可以在http://nvie.com/posts/a-successful-git-branching-model/找到。

+0

問題是我有幾個相互依賴的長期功能分支。您描述的工作流程很簡單(幾乎是我的大型工作流程的一部分)。 – 2010-10-29 13:11:58