門控承諾使用Git分支

Question

我期待到建立使用Git分支像這樣每個開發者一個門提交的工作流程：

1. 每個開發者都有自己的遠程分支。
2. 開發人員只會將他們推送到他們的遠程分支。
3. C.I服務器單獨構建每個分支並在測試通過時合併到主控中。
4. 開發人員通過將其分支拖放到主設備上來接收更改。

這是一個合理的解決方案嗎？我來自顛覆，對git沒有太多經驗。

Answer 1

我認爲這個評價通常是合理的。我會盡量不把分支想象成'遙遠'。這是顛覆轉變的一部分。所有開發人員都具有用於與實際遠程存儲庫同步的本地和遠程（分段）區域（'起源'）。開發人員應該經常與主分支進行合作並進行推動和重新設計（與時俱進）。對在工作流

更多信息：git branch, fork, fetch, merge, rebase and clone, what are the differences?

我的工作流程是：

• 拉最新主
• 做一個分支
• 做工作
• 更改提交到分支
• 取指最新主人
• 合併掌握到分支
• 做更多的工作
• 更改提交到分支
• 獲取最新力作
• 合併掌握到分支
• 代碼審查
• 切換到主
• 獲取遠程主的最新遠程版本
• 合併分支到主人
• 將主人推送到遠程

Answer 2

根據我個人的經驗，過去最適合我團隊的工作流程是讓所有開發人員共享一個遠程分支。對於我的團隊來說，我們只是把這個分支稱爲「主人」。我們的分支策略借鑑了這篇文章的想法：a-successful-git-branching-model。只需將文章中的「開發/主」分支與「主/發佈」互換，並且您基本上擁有了我的設置。這是一樣的，只是標記不同。

我基本上讓我們所有的開發人員都承諾掌握，但只有提交合並的約定。所有直接編碼都發生在主題分支上。對於只有一個變更集的快速修復，可以直接向母版提交。但總的來說，強烈鼓勵使用本地話題分支。

此外，所有提交給主的提交必須立即推送，否則差異會累積並使合併更難。通過這種方式，解決合併的負擔是開發人員的責任，而不是團隊負責人或一些自動化軟件。這是理想的情況，因爲開發代碼的人通常最瞭解自己的變化。

如果不止一個開發人員需要在單個主題分支上工作，我允許所有開發人員將他們自己的分支在特定路徑下推送到遠程（在我的情況下，它是「共享/」），以便其他人可以將從它推。

至於測試服務器（CI服務器），它會在每次測試運行時更新它的主站和分支。在新分支上測試並不是必須的，但是我知道某些自動化腳本不直接在master上工作，所以我更加舒適。

如果你來自svn，在共享分支上發生不斷的小變化可能看起來有點可怕。不要害怕，git通常非常擅長解決衝突，並且90％的時間內不會引發衝突git merge或git pull。

最後，確保你經常灌輸你的開發者經常的習慣，經常拉。小的增量更改實際上有助於更好地合併代碼。

Answer 3

使用Gerrit - 它基本上完全是一個門控犯了代碼審查解決方案建立在功能

。