Git分支开发管理实践

目录

1. 概要

2. 分支分类

3. 分支管理策略

4. 代码管理规范

5. 代码分支创建合并流程

---

1. 概要

        基于git的版本管理实践，主要包括：分支分类、分支管理策略、代码管理规范、代码分支创建合并流程。

2. 分支分类

        根据分支的位置及作用，分为以下四种分支：

• 远程主分支：位于远程git仓库，所有开发的代码最终都要合到主库。
• 远程开发分支：开发过程中的代码会存储在远程开发分支。
• 本地主分支：从远程仓库clone工程到本时，默认是主分支。
• 本地开发分支：每次根据需求从主分支创建开发分支出来，每个开发人员完成开发后push到远程开发分支；完成版本需求开发后，由版本人员合并开发分支代码至主分支后，push到远程仓库主分支。

3. 分支管理策略

        通常采用分支开发+主干发布模式：

        所有的代码提交都在分支上操作，系统上线需要构建Release版本时，需要将代码合并到主干上面，平常开发都是在分支上进行，可保证主干代码始终可用。

        需求分支合并到主干上线完成后，后续变更需求需要创建新的branch。

4. 代码管理规范

1. 原则上代码的开发提交，必须通过创建分支进行开发，特殊情况除外（sonar bug）。
2. 主分支为生产环境分支，除特殊情况（修复bug），禁止在主干分支上进行开发。
3. 需求分支（分支名称由代码版本管理员根据需求内容进行创建）为开发分支，一般作为主要的代码提交分支。
4. 其他分支，为特殊情况建立的分支，命名应带有分支相关信息。
5. 在代码开发阶段，代码的提交尽量独立化，也就是功能模块尽量细分，每个开发负责一个模块，尽量不要修改其他成员模块代码。
6. 多人协作时，需要创建一个需求分支，然后一起在需求分支里协作开发，防止代码被覆盖。禁止各自开发，然后线下发送文件合并。
7. 代码提交前，必须先进行更新代码（git pull），对于有冲突的文件，必须要进行对比，确认所有修改都是自己修改的，然后在进行提交，防止代码被覆盖。
8. 代码出现冲突时，必须要与冲突代码提交者进行确认冲突内容，双方确认无误方可处理。
9. 提交代码必须先compare，确认没有冲突之后再进行pull，然后再将本地的代码进行commit，最后进行push。
10. 代码提交时，必须描述清楚做了什么，描述信息制定统一格式。
11. 在git中，默认空目录不会提交，如果某个空目录想提交到版本库，需要在该目录下新建一个deleteme.txt的空白文件。

5. 代码分支创建合并流程

• 分支创建：代码版本管理员根据需求文档、概要设计以及相关的会议评审纪要才能创建需求开发分支。
• 分支合并：需求开发分支在测试环境发布、测试通过且sonar扫描bug修复完成之后，再将开发分支合并到主干，主干发布到测试环境，复测通过之后才算合并完成。
• 分支删除：通常情况下，没必要删除，如果迭代版本太多，可以制定删除规则进行删除。