分支开发工作流
由于分支管理的便捷, 才衍生出这些典型的工作模式,你可以根据项目实际情况选择。
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
)清理无用分支。