分支开发工作流
由于分支管理的便捷， 才衍生出这些典型的工作模式，你可以根据项目实际情况选择。
1. 长期分支
- 适用于持续开发和发布周期长的项目。常见的长期分支包括：
-
master：只保留稳定的代码，通常用于生产环境。develop或next：用于开发中的功能，可能不稳定，但在达到一定稳定性后可以合并到master分支中。
- 在此模式下，开发者可以创建不同的分支来处理新功能或修复问题，并定期将这些分支合并到
develop或master分支中，保持项目进度和稳定性。
1.1. 趋于稳定分支的线型图：
- 通常把他们想象成流水线（work silos）可能更好理解一点，那些经过测试考验的提交会被遴选到更加稳定的流水线上去。
-
1.2. 趋于稳定分支的流水线（“silo”）视图
- 可以用这种方法维护不同层次的稳定性。 一些大型项目还有一个
proposed（建议） 或pu: proposed updates（建议更新）分支，它可能因包含一些不成熟的内容而不能进入next或者master分支。 这么做的目的是使你的分支具有不同级别的稳定性；当它们具有一定程度的稳定性后，再把它们合并入具有更高级别稳定性的分支中。 再次强调一下，使用多个长期分支的方法并非必要，但是这么做通常很有帮助，尤其是当你在一个非常庞大或者复杂的项目中工作时。 -
2. 主题分支
- 一种短期分支，通常用于开发单个功能或处理特定问题。这种模式下，开发者可以创建多个独立的分支来处理不同任务，每个分支专注于一个独立的特性或改动，开发完成后再合并回主分支。主题分支允许快速的上下文切换，使得不同功能或问题的开发不会互相干扰，且合并时不影响主分支。
- 示例：
-
-
- 合并了
dumbidea和iss91v2分支之后的提交历史 -
-
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）清理无用分支。
