功能分支的Git Rebase或SVN重新集成？

Question

我們目前正在使用SVN，但考慮轉移到Git來支持我們新的工作流程，這個工作流程嚴重依賴於rebase。

我們正在考慮其中每個單獨的功能在一個單獨的分支開發的開發流程，然後合併到主幹/主當它準備發佈。分支合併回主幹/主設備後，該分支將始終被刪除。

一個建議是使用git rebase通過master中的變化保持特性分支的最新狀態（這樣我們就可以在分支中精確地測試將要發佈的內容）並簡化分支 - > master的合併。

我們正在考慮的另一種方法是使用svn merge來保持特性分支與主幹中的更改保持一致，然後使用svn merge --reintegrate將特徵分支重新合併到主幹中進行發佈。

每種方法的差異和潛在缺陷是什麼？哪個更適合我們的工作流程？

Answer 1

這是一個非常簡單的git工作流程。一些開發人員使用您描述的一種或兩種方法。

個人而言，我的scott Chacon's strategy風扇和發現它真的很有用。

您可以變基，以保持主分支在一個線性的歷史，這是正常的，但它確實有拋出一些大循環，以人剛剛開始的git出輕微的可能性。如果您不小心，重新更改歷史記錄並確實會導致問題。

Git的合併（而不是SVN合併--reintegrate你提到的）是一個小混帳中更直接，如果你是剛剛起步。 Git的合併策略是非常深思熟慮的，並且可以自動讓您擺脫困境。

如果我開發的特性分支，然後將其合併到主，我喜歡跑步git merge --no-ff feature而在主創建合併提交剛需明確。

正如您剛剛使用Git開始，我會去的合併工作流程。恕我直言，它更直觀，如果你來自SVN背景。