部署Git工作流掛了一個小團隊

Question

知道如果這是一個合理的方法來使用Git有一個小團隊：

1. 我們有「主」分支。 Git默認爲我們創建這個分支。
2. 開發人員A和B將「主人」克隆到他們的本地機器。
3. 開發人員A運行：[git branch devA]創建本地分支。他們通過運行[git checkout devA]來切換到它。
4. 開發人員B運行：[git branch devB]創建本地分支。他們通過運行[git checkout devB]切換到它。
5. 對於開發者A來說，他們將本地分支轉變爲遠程分支，他們將運行：[git push origin devA]。開發者B對他們的本地分支做同樣的事情。
6. 現在，如果使用GitHub，我們會在項目頁面上看到這兩個遠程分支。
7. 這兩個開發人員都改變了他們的本地分支，並且運行[git push]將他們的提交推送到他們各自的遠程分支（我們會看到這反映在github上）。

這對我來說似乎是一個合理的工作流程。現在是開發人員合併所有工作以發佈他們正在開發的應用程序的時候了。我的理解是：

1. 開發人員A想要將開發人員B的更改導入其分支。開發人員A會運行：[git pull origin devB]。
2. 我們可能會創建另一個名爲「dev」的遠程分支，它用作每個人更改的中央存儲庫：[git branch dev]，[git push origin dev]。
3. 其中一個開發人員切換到分支「dev」。他們把每個人的變化都拉進去：[git pull origin devA]，[git pull origin devB]。所有的衝突都是固定的。
4. 當所有衝突都固定在「dev」後，我們切換到分支「master」，並將「dev」拖入其中：[git branch master]，[git pull origin dev]。

所以這個想法是，所有的開發人員在他們自己的本地分支上工作，並定期合併到「開發」的東西。只有在發佈時，纔會有人從「開發者」變成「主人」。所以「主」總是包含最後發佈的代碼。

這是否合理？

謝謝！

Answer 1

這個工作流可能會很好，但它有一些你可能想要考慮的問題。

它並沒有反映出每個分支代表一個「特徵」或「主題」 - 工作價值的常見Git理念（例如，請參閱Junio Hamano on the purpose of branches）。但是，這不會阻止它成爲您團隊的可行工作流程。

反映這一理念

一種流行的工作流程是git flow。

另一個受歡迎的工作流程是workflow that the GitHub dev team uses，它直接違背了Junio關於將主人合併到功能分支中的內容，有利於保持心智模型更簡單，並避免向開發人員解釋重定向。

另一個問題是，此工作流程不鼓勵頻繁集成。所以德瓦和發展局可以顯著分歧，開發商可能需要做的工作很多在時機成熟時合併。

Git本身並不在乎，所以如果你的開發者很開心，那麼你的建議似乎可行。

Answer 2

假設您有兩個以上的開發人員，您是否希望一位開發人員能夠從其他特定開發人員那裏獲取更改，但不包括來自所有其他開發人員的更改？如果沒有，我不認爲有必要創建任何開發者分支機構。每個人都會檢查以掌握自己的存儲庫;每個人都在推動原點的掌握;每個人都可以獲得所有推送的更改，從所有開發人員合併到每個推送。

至於在起源的主對開發分支，你可以這樣做;更典型的是，我認爲，主人是正在進行的工作，每個穩定版本都有自己的分支。