概述
分支成功
源代码控制对于从事重要项目的任何开发人员或单个开发人员来说都是一个巨大的好处。它允许您管理来自开发人员的多个同时贡献，将时间回滚到之前的任何时间点，并提供方便的备份以防代码的本地副本出现问题。然而，任何提供如此多好处的工具通常都会将其自身的复杂性引入到流程中。下面我们将看看这些复杂性之一——分支方案。我们将重点关注 Git，但一般概念应该适用于任何具有分支功能的源代码控制产品。
注意事项
分支方案旨在解决开发团队常见的许多问题。有能力的分支方案的一些示例好处是：
- 分支允许开发人员单独处理新功能，从而降低覆盖其他开发人员更改的风险。
- 分支允许开发人员运行实验，使用各种不同版本的底层源代码，而不会影响底层产品。
- 分支允许快速轻松地回滚有问题的功能（有一些警告）。
- 分支允许隔离生产代码，减少或消除在确定已部署哪些代码时的混乱。
- 分支允许功能可测试性，让 QA 资源有机会在隔离和集成场景中测试功能。
选择分支方案时，您的开发组织应该做的第一件事就是确定这些考虑因素中哪一个最重要，以及您的分支方案如何解决每个问题。
Gitflow 工作流程
开发组织中最常用的分支方案之一是 GITFLOW WORKFLOW 。这种分支方案旨在提供一种管理整个开发过程的方法，使用分支来管理发布、功能开发，甚至生产修补程序。在非常高的层次上，它利用了以下概念：
- 代码分为五类分支——master、develop、feature、release和hotfix。
- master 分支仅包含当前部署到生产环境中的代码。
- 开发分支作为下一组准备部署到生产中的功能的组合功能分支。
- 功能分支是大多数日常开发工作发生的地方，开发人员在将其合并回开发之前在单独的功能分支中完成他们的功能。
- 当已经完成足够的功能以满足下一个版本的标准时，发布分支将在开发分支之外创建。发布的 QA 通常在此分支上进行。批准发布后，发布分支将合并到 master 和 develop – master 以将代码部署到生产环境，并 develop 以获取添加到发布分支的任何 QA 修复。
- Hotfix 分支是在 master 之外创建的，以响应生产问题。功能完成和测试后，修补程序将合并到 master 以进行部署和开发，以确保更改不会在未来的开发中丢失。
以上处理了之前讨论的所有标准。它允许在功能分支上单独测试功能，以及在发布或开发分支上以集成状态测试功能。它使您可以清楚地了解通过 master 分支部署到生产中的确切内容。它允许开发人员独立地处理他们自己的功能，并通过让他们成为执行合并的开发人员的责任来最大限度地减少合并冲突。最后，它有助于降低代码回滚的复杂性，因为所有开发都有一个明确的合并点，在这个合并点中，功能被完整地引入到代码库中。您可以 在此处 阅读有关 Gitflow 工作流的更多信息。
GitHub 流程
Gitflow Workflow 的常见抱怨之一是它使持续部署变得难以管理。对于某些组织，在开发分支和部署分支之间增加额外的步骤会降低他们期望的开发速度。 GitHub Flow 遵循以下模式：
- “主”分支中的任何内容都是可部署的
- 新开发发生在从主分支分支出来的具有描述性名称的分支中
- 当分支准备好时，或者如果开发人员希望得到反馈，将创建一个 git pull 请求来审查代码
- 拉取请求一旦获得批准，就会合并到主分支中
- master 分支上的更改可以——而且应该——立即部署
很明显，这种分支方案优先考虑频繁部署。这并不是说不负责任的部署——所有特性在进入 master 分支部署之前仍然经过测试和验证——而是对团队开发和 QA 实践的信心，允许这种快速部署。您可以 在此处 阅读有关 GitHub Flow 的更多信息。
其他选择
虽然 Gitflow 和 GitHub Flow 是当今工业界使用的两种主要分支方案，但它们绝不是分支方案问题的唯一答案。例如，一些组织使用 Gitflow Workflow 的修改版本，让开发人员派生基础存储库并在他们自己的本地存储库副本中工作，要求所有代码通过拉取请求发送到主存储库。其他人则相反，使用分支来管理同步的多版本开发和发布方案——这些在为一系列客户定制软件时最有用。无论您想要的分支方案是什么，很可能某处某个组织使用非常相似的方案。
结论
Gitflow 和 GitHub Flow 等分支方案旨在减少为实现单一目标而工作的开发人员团队之间的集成和测试问题。然而，它们并不是分支问题的唯一可能解决方案。在选择分支方法之前，对您的开发组织及其实践进行分析很重要。在依赖大量代码测试和验证的组织中使用 GitHub Flow 可能是不可取的，而在优先考虑部署速度的组织中使用 Gitflow Workflow 将证明很麻烦。正确答案因每个开发团队而异——了解每种方法的优点和缺点很重要。
