一种好的分支策略，是可以允许多个团队在同一个存储库上工作，并可以通过分支命名明确的知道这个分支是干什么的。

首先来说一下核心原则

核心原则

1. master 这是每个开发的起点，主分支受到保护的。你的新代码必须从这里开始，你可以确定那里的一切已经经过100%的测试并已经上线。由于该分支受到保护，人员不允许手动合并任何内容，也不允许通过PR进行合并，因此不会有任何意外。
2. 分支使用前缀 使用前缀有助于更轻松地查找分支并理解其目的。不必逐个审查分支时，清理GIT也更容易。
3. 使用描述性的分支名称 前缀是一回事。描述性的名称对于帮助理解我们正在查看的内容至关重要。使其对人友好且易读。
4. 正确的版本控制 版本控制会影响发布分支的名称，因此更容易找到并推送它们而不影响其他团队的工作流程。
5. 尽可能自动化 分支创建、版本控制、合并。这需要一些工作，但与任何其他发布自动化流程相比，并没有什么不寻常或更复杂的事情需要做。

关于前缀的命名

1. master/main — 始终代表当前上线的内容。

2. wip/name — 这些分支主要用于实验性工作、POC和其他非基于任务的任务。 “WIP”表示它无法独立上线，可能是一个重要功能或工作流的一部分。它还可能是一个临时的集成分支。可以将这些分支推送到开发服务器进行测试。

3. feature/#####-name — 这些分支将用于开发和测试新功能/任务/错误修复。在提交到发布之前，可以将它们推送到服务器进行测试。如果有助于将代码与任务连接起来，使用#####来表示任务编号。

4. release/X.XX — 发布分支是由构建过程自动创建的，所有代码都将合并到这里以进行上线。分支名称是使用主要和次要版本号的版本。永远不要为“更新”创建分支。

5. integration/name — 有时我们会遇到一些作为更大功能的任务，它们必须一起测试并上线。这些通常被视为长期存在的分支，并允许持续开发和PR来创建最终的功能/项目。

6. hotfix/#####-name — 从我们想要应用修复的特定发布创建的分支。

   注意：我们决定永远不删除发布分支，每当我们需要查看历史记录、在特定时间检查代码或审查更新时，分支都是可用且易于找到的。

优点：

• 它在许多方面介于 GitFlow 和 GitHub Flow 之间，但澄清并简化了一些无法解释的领域。
• 它非常适合由于额外的手动步骤、审批流程或时间问题而无法实施完整 CD 的情况。
• 非常适合单一存储库，其中多个应用程序构建在共享核心上，并由具有不同交付时间表和优先级的各个团队开发。
• 将能够轻松地单独创建一个版本，对其进行测试、部署，只有在 100% 正常后，才将其合并回 Master。这意味着如果代码因尚未测试而失败，没有人会感到恼火。
• 多个团队可以从同一存储库为不同的应用程序创建版本并部署它们，而不会相互阻塞。
• 轻松同时管理多个版本并在实时推送代码之前同步它们。
• 无需开发分支。忘掉它。
• 由于版本控制是由构建过程和管道控制的，因此发布分支命名不会发生冲突。
• master/main分支始终可以安全地用于新版本。可以相信，没有未经测试的代码或令人讨厌的意外。
• 无需依赖哈希值或标签，使所有内容都易于阅读，但每当发布版本被推送并合并回主版本时，留下标签仍然是一个好习惯。
• 功能（在发布分支上）只要准备好并经过测试就可以上线。
• 由于每个版本都是一个单独的分支，因此可以直接回滚或在此特定分支上进行更新并发布任何应用程序。
• 不会因未完成的代码或等待依赖项或其他团队而导致发布周期锁定。
• 鼓励合并前进行测试。
• 为开发人员创造更少的认知开销，因为分支由发布管道维护（假设有适当的自动化）。
• 如果出于任何原因不再需要某个版本，则很容易放弃该版本。
• 将CI 和自动部署的流程扩展到开发环境有很大的潜力。

缺点：

• 每个版本的发布分支名称都会改变，因此可能需要编写更智能的管道，因为不会从一个分支（通常是主分支）发布。
• 持续交付的自动化更加困难，但并非不可能。
• 开发人员需要跟踪正在进行的版本。
• 在合并到发布分支之前，需要确保正在处理来自主分支的最新代码（将其合并）。
• 如果团队正在开发一项重要功能并且需要对其进行测试，那么可能（不必）在将其全部推送到发布之前最终使用集成分支。
• 由于在开发过程中 master 中的情况可能会发生变化，因此必须稍后将其合并，并且可能会产生一些需要解决的额外冲突。
• 当所有团队成员都以某种隔离方式工作时，在发布分支中相遇时，会遇到冲突。
• 如果不考虑适当的版本控制和管道自动化，这一切可能都毫无意义。

发布流程很重要！

管道控制如何创建每个版本的分支、版本控制以及使用相关更改正确更新以避免错误。最重要的是，负责安全地推送代码并将所有内容合并回 master。

举个栗子

1. 简单

两个开发人员正在准备两个功能并一起发布它们。

2. 典型

一些功能、一个发布分支和一个后期合并。

3. 常规特征和一个很长的特征。两个版本。

一个功能需要很长时间的流程。基本上，在合并到发布之前，再次合并到 master 中以保持 100% 最新。

4. 放弃发布。

当一个版本开始时，另一个版本随后创建，但在第一个版本之前上线（可能是快速修复）。可以通过在管道中采取一些额外的保护措施来防止这种情况，从而避免一次创建多个“正在进行中”的版本。此外，可以使用修补程序来代替小更新。

5. 发布后进行修改。

如果对现有实时代码有简单的错误修复，则可以使用修补程序。这将帮助你避免陷入上述情况。修补程序用于通过一个小但重要的补丁来更新现有版本。

6. 还有更多事情发生。

请注意，不同的人和团队可能会处理这样的示例。它可能看起来很复杂，但如果你遵循两个简单的规则，它就会很顺利。

• 始终确保你已将 master 合并到发布分支并且版本正确。
• 与团队发布计划和正在进行的分支进行沟通（通常，团队会共同创建一个版本并将其推出）。

可能每个团队的流程都不一样，但是我想应该都是大同小异。

点赞收藏支持、手留余香、与有荣焉，动动你发财的小手哟，感谢各位大佬能留下您的足迹。

往期热门精彩推荐

面试相关热门推荐

实战开发相关推荐

移动端相关推荐

Git 相关推荐