Git 分支最佳實踐——master、production、staging？

Question

我試圖了解 master 分支的目的。 每個新的 repo 都從一個開始，我做過幾項工作，在 repo 初始化后從未觸及過 master 分支，而生產是部署到生產的最后一個分支。 例如

somefeature => qa => staging => 生產 ==> 部署

甚至沒有 QA 分支：

somefeature => staging（充當 qa）=> 生產 ==> 部署

鑒於沒有硬性規則，對於分支，特別是 staging、production 和 master，什么是合理常見的方法？

Answer 1

有多種常見的分支方法，您使用哪一種取決於您的需要。

如果您正在運行自己的源代碼，則可以使用單個主分支（例如master ）。 在這樣的 model 中，您創建一個 PR 並獲得所有必需的批准。 然后，您使用單獨的部署工具（例如機器人）在分支系統之外進行部署，並在代碼穩定時合並到主分支中。 GitHub 使用該系統。

您可能還希望使用分層分支 model，其中 PR 合並到一系列分支中，首先是開發分支，然后是 QA 分支，暫存分支和生產分支。 后者可能稱為也可能不稱為master 。

如果您正在處理基於發布的項目，您可以擁有一個大多數代碼合並到其中的開發分支和一個或多個發布分支，如果需要，修復會在其中被挑選出來。 這是很多開源項目使用的model，比如Git LFS。 Git 使用類似的策略，但有額外的分支，其中更改“烹飪”直到它們被認為是穩定的。

還有其他更復雜的工作流程，例如 Git Flow，它們可能或許多不能滿足您的需求。 分支策略要考慮的一件事是，如果您有多個分支，您將如何通過各個階段獲取代碼。 您可能希望有一個機器人或工具來引導事情通過初始 PR 或分支之后的各個階段，否則事情很容易迷失方向。

重要的是您清楚地記錄您的工作流程，以便每個人都知道它是如何工作的，並且如果它不再滿足您的需求，您願意重新審視您的工作流程。 您可能會發現，如果事情對您不起作用，您可能需要更改除分支策略之外的工作流部分，如果這對您的項目或組織更有效，則可以進行這些更改。

但總的來說，很難做出一刀切的推薦。

Answer 2

如果你不熟悉 git-flow，這是一個非常合理的分支策略：

https://nvie.com/posts/a-successful-git-branching-model/

關於 master 分支，請記住，“master”只是分配給 git 存儲庫的第一個分支的默認名稱。 不多也不少。