最佳實踐：工作流程：何時合併到不同類的團隊中

Question

我是使用SCRUM和使用Git的學生程序員團隊的技術經理。

我們用下面的分支模型： http://nvie.com/posts/a-successful-git-branching-model/

雖然我只是工作的一半一週每當套房最他們的日程安排/個人需求（也週末或有時在深夜學生計劃）。

現在我們有不同的要求認爲（在我看來）不要去太融洽：

一方面作爲誰的技術責任，我想查看一個在它進入開發分支之前的代碼，並且能夠檢查代碼是否存在單元測試，遵守一般的編碼風格和可維護性。 。

在另一方面我希望我的隊伍非常經常合併，這樣沒有合併發生衝突（或者至少留儘量少

• 這是一個共同的問題 - 哪些人有已經發現 一個行之有效的解決方案
• 難道我在這裏有一個非常特殊的問題，你有 一個想法如何解決這個問題
• 難道我進入了錯誤的方向這樣想 - ？？？是我的前提 莫名其妙假？

Answer 1

這就是你可以採取的Git的分佈式特性的優勢：

你可以讓他們在一個專用的「QA」回購的Dev分支，這反過來會推到最後集中合併回購如果提交被批准。

理想情況下，質量保證回購是一個gerrit之一，這是爲了便於審查過程。

但總體思路，以DVCS，就是：你不必只是合併的工作流程（從一個分支合併到分支），你也有一個publication workflow（從回購推到upstream repo）。