不在Git的master分支上工作的原因

Question

所以，我對git還是比較陌生的，在過去的幾個星期裏我經過了一些閱讀，我已經讀過一些人說，master分支不應該改變，而應該分支併合並。

我很高興能夠與分支機構合作，但想知道不支持master分支的原因嗎？

Answer 1

我想通常的推理是，主分支應代表您的代碼的'穩定'歷史。使用分支來試驗新功能，實施它們，當它們足夠成熟時，可以將它們合併回主設備。

這樣，master中的代碼將幾乎總是沒有問題地構建，並且可以直接用於發佈。

讓我們以git.git（官方git倉庫）爲例。有幾個分支，最值得注意：

• master
• next
• pu
• maint

所以，master包含的代碼，這是非常有可能在下一版本落得飯桶。 next包含測試代碼，可能會合併到master分支中。 pu（提議的更新，iirc）包含相當新的（可能）未經測試的代碼。

pu被認爲是不穩定的，將被重新設置並重新設置爲junio的喜好。 next可能會在發佈後或發佈週期中得到重置，但這種情況並不常見。 master被設置在石頭上，並且在被推送並公開可用之後永不改變。

你看到，改變將獲得合併從pu到next和next到master，如果他們認爲值得與不破的東西。

分支maint用於進行錯誤修正，它也應該適用於舊版本的git。 maint通常合併爲next和/或master。

您可以檢查在http://git.kernel.org/?p=git/git.git;a=summary

Answer 2

在雙方進行提交時 - 這意味着在本地存儲庫和上游例如來自其他團隊成員 - 可能發生衝突。這意味着文件和特定行都是由兩者編輯的。在這種情況下，一些手動合併處理是必要的。

master分支用於在無法訪問上游（移動使用或網絡故障）時擁有代表上游的本地分支。當擁有一個代表上游變化的本地分支時，合併解析和其他東西要容易得多。

Answer 3

的一件事，你需要用一個DVCS（分佈式版本控制系統）如Git或水銀要考慮的是「公佈」工作流程（orthogonal to the branching workflow）的分支機構。

當你只有分支，你會問自己，他們代表什麼樣的發展努力。
如果master是爲了代表穩定的代碼，如knittl中的細節his answer，那麼是的，你需要從/合併到master。

但是，當您可以克隆/推/拉（即發佈到不同的回購協議，其本身可能有不同的目的）時，'master'可以從回購協議到回購協議發揮不同的作用。

• 一個開發回購可以有很多分支，而master通常代表最穩定的代碼。
• 部署回購只能有master，以及一些修補程序維護分支進行緊急修復。
• 本地測試回購只能有一個master分支，從推重寫，以使只是爲了通過監視鉤運行一些靜態分析代碼只說master分支該測試回購。
• ...

Answer 4

其他人都取得了很好的情況下，直接在master沒有進行更改，我同意他們的觀點。然而，總是提倡這樣的工作流程有時會讓人們不敢相信它是不必要的複雜，所以我想提供一個對應點。

如果你有一個人或一個非常小的團隊，並且你的開發是高度線性的，即你很少一次在一件以上的東西上工作，每個功能通常在開始下一個之前就完成了，沒有直接從master工作的好處。如果需要，隨時可以返回並添加分支。我強烈建議您瞭解功能分支工作流程，但如果您覺得您的情況只是增加額外的步驟而不會購買任何東西，我保證我不會告訴git警察。