​

分支开发工作流

由于分支管理的便捷， 才衍生出这些典型的工作模式，你可以根据项目实际情况选择。

1. 长期分支

• 适用于持续开发和发布周期长的项目。常见的长期分支包括：

1. 1. master：只保留稳定的代码，通常用于生产环境。
   2. develop 或 next：用于开发中的功能，可能不稳定，但在达到一定稳定性后可以合并到 master 分支中。

• 在此模式下，开发者可以创建不同的分支来处理新功能或修复问题，并定期将这些分支合并到 develop 或 master 分支中，保持项目进度和稳定性。

1.1. 趋于稳定分支的线型图：

• 通常把他们想象成流水线（work silos）可能更好理解一点，那些经过测试考验的提交会被遴选到更加稳定的流水线上去。

• ​

  编辑

1.2. 趋于稳定分支的流水线（“silo”）视图

• 可以用这种方法维护不同层次的稳定性。 一些大型项目还有一个 proposed（建议） 或 pu: proposed updates（建议更新）分支，它可能因包含一些不成熟的内容而不能进入 next 或者 master 分支。 这么做的目的是使你的分支具有不同级别的稳定性；当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。

• ​

  编辑

2. 主题分支

1. 一种短期分支，通常用于开发单个功能或处理特定问题。这种模式下，开发者可以创建多个独立的分支来处理不同任务，每个分支专注于一个独立的特性或改动，开发完成后再合并回主分支。主题分支允许快速的上下文切换，使得不同功能或问题的开发不会互相干扰，且合并时不影响主分支。
2. 示例：

1. 1. ​

      编辑

   2. 合并了 dumbidea 和 iss91v2 分支之后的提交历史

   3. ​

      编辑

3. ⭐总结

3.1. 概念/定义

分支开发工作流是利用 Git 的强大分支功能，灵活管理项目开发的方式。通过短期和长期分支的结合，可以更好地组织代码，确保代码稳定性并支持团队协作。

3.2. 基本操作

3.2.1. 长期分支

• 定义：用于维护不同稳定性级别的代码，例如：

• • master 分支：仅包含完全稳定或已发布的代码。
  • develop 或 next 分支：包含正在开发或测试中的代码。
  • 其他如 proposed 分支：用于存储不成熟或待验证的更新。

• 特点：定期将主题分支合并到更高稳定性的分支中。

3.2.2. 主题分支

• 定义：短期分支，用于开发单一特性或解决单个问题。
• 特点：

• • 灵活性：可以随时创建、合并、删除主题分支。
  • 上下文独立：每个主题分支专注于特定目标，方便审查和管理。
  • 保留时间：改动可以在主题分支中保留任意时长，待成熟后再合并。

3.2.3. 操作示例

• 创建分支开发方案：

• • 从 master 创建 iss91 分支，工作到 C4。
  • 创建 iss91v2 进行第二种方案的尝试。
  • 临时创建 dumbidea 分支测试新的想法。

• 合并分支后历史示例：最终合并 iss91v2 和 dumbidea，抛弃 iss91 分支。

3.3. 优点/好处

• 并行开发：支持多个任务同时进行，互不干扰。
• 代码稳定性：通过分支间的逐步合并，确保主分支稳定。
• 便于审查：分支聚焦特定任务，改动清晰易懂。
• 灵活调整：随时切换分支或丢弃不合适的方案，最大限度保留有效成果。

3.4. 风险/注意事项

• 本地分支操作：未推送的分支操作仅在本地生效，需同步到远程仓库以便团队协作。
• 分支过多：分支数量庞大时需定期清理，避免代码库冗杂。
• 合并冲突：频繁操作可能导致冲突，需及时解决。

3.5. 使用建议

• 长期分支策略：为不同稳定性级别的代码维护明确的长期分支（如 master、develop）。
• 小步快跑：尽量使主题分支短小精悍，单一任务完成后及时合并或删除。
• 团队协作：推送主题分支到远程仓库，让团队成员了解进度或进行协作。

3.6. 配置建议（如适用）

• 分支保护：保护 master 或关键分支，避免直接提交，强制通过 Pull Request 合并。
• 分支命名规范：遵循如 feature/xxx 或 hotfix/xxx 的分支命名规范，便于团队理解和管理。
• 分支清理工具：定期使用工具或命令（如 git branch -d 和 git branch -r）清理无用分支。

​