Git 分支最佳实践 - master、production、staging？
Git branch best practices - master, production, staging?
我正在尝试了解 master 分支的用途。每个新的回购都是从一个开始的，我做过几份工作，在回购的初始化和生产是部署到生产的最后一个分支之后，主分支从未被触及过。例如
somefeature => qa => staging => production ==> deploy
甚至没有 qa 分支：
somefeature => staging（作为 qa）=> production ==> deploy
鉴于没有硬性规定，分支的合理通用方法是什么，尤其是暂存、生产和主控？
如果你不熟悉git-flow，那是一个非常合理的分支策略：
https://nvie.com/posts/a-successful-git-branching-model/
关于 master 分支，请记住“master”只是分配给 git 存储库第一个分支的默认名称。不多也不少。
有多种常见的分支方法，您使用哪种取决于您的需要。
如果您是 运行 自己的源代码，您可能只需要一个主分支（例如 master）。在这样的模型中，您创建一个 PR 并获得所有必需的批准。然后，您使用单独的部署工具（例如机器人）在分支系统外部进行部署，并在代码稳定时合并到主分支。 Git集线器使用此系统。
您可能还希望使用分层分支模型，其中将 PR 合并到一系列分支中，首先是开发分支，然后是 QA 分支、登台分支和生产分支。后者可能称为也可能不称为 master.
如果您从事的是基于发布的项目，您可以拥有一个大多数代码合并到其中的开发分支，以及一个或多个发布分支，其中修复在必要时被精心挑选。这是许多开源项目使用的模型，例如 Git LFS。 Git 使用类似的策略，但有额外的分支，在这些分支中更改“烹饪”直到它们被认为是稳定的。
还有其他更复杂的工作流，例如 Git Flow，它们可能或许多不满足您的需求。分支策略需要考虑的一件事是，如果您有多个分支，您将如何通过这些阶段获取代码。您可能希望有一个机器人或工具来指导初始 PR 或分支之后的各个阶段，否则很容易丢失东西。
重要的是清楚地记录您的工作流程，这样每个人都知道它是如何工作的，并且如果它不再满足您的需求，您愿意重新审视您的工作流程。您可能会发现，如果事情不适合您，您的工作流程中除分支策略之外的部分可能需要更改，如果对您的项目或组织更有效，则可以进行这些更改。
但总的来说，很难提出一个放之四海而皆准的建议。
我正在尝试了解 master 分支的用途。每个新的回购都是从一个开始的，我做过几份工作，在回购的初始化和生产是部署到生产的最后一个分支之后，主分支从未被触及过。例如
somefeature => qa => staging => production ==> deploy
甚至没有 qa 分支：
somefeature => staging（作为 qa）=> production ==> deploy
鉴于没有硬性规定，分支的合理通用方法是什么，尤其是暂存、生产和主控？
如果你不熟悉git-flow，那是一个非常合理的分支策略：
https://nvie.com/posts/a-successful-git-branching-model/
关于 master 分支，请记住“master”只是分配给 git 存储库第一个分支的默认名称。不多也不少。
有多种常见的分支方法，您使用哪种取决于您的需要。
如果您是 运行 自己的源代码，您可能只需要一个主分支（例如 master）。在这样的模型中，您创建一个 PR 并获得所有必需的批准。然后，您使用单独的部署工具（例如机器人）在分支系统外部进行部署，并在代码稳定时合并到主分支。 Git集线器使用此系统。
您可能还希望使用分层分支模型，其中将 PR 合并到一系列分支中，首先是开发分支，然后是 QA 分支、登台分支和生产分支。后者可能称为也可能不称为 master.
如果您从事的是基于发布的项目，您可以拥有一个大多数代码合并到其中的开发分支，以及一个或多个发布分支，其中修复在必要时被精心挑选。这是许多开源项目使用的模型，例如 Git LFS。 Git 使用类似的策略，但有额外的分支，在这些分支中更改“烹饪”直到它们被认为是稳定的。
还有其他更复杂的工作流，例如 Git Flow，它们可能或许多不满足您的需求。分支策略需要考虑的一件事是，如果您有多个分支，您将如何通过这些阶段获取代码。您可能希望有一个机器人或工具来指导初始 PR 或分支之后的各个阶段，否则很容易丢失东西。
重要的是清楚地记录您的工作流程，这样每个人都知道它是如何工作的，并且如果它不再满足您的需求，您愿意重新审视您的工作流程。您可能会发现，如果事情不适合您，您的工作流程中除分支策略之外的部分可能需要更改，如果对您的项目或组织更有效，则可以进行这些更改。
但总的来说，很难提出一个放之四海而皆准的建议。