Git分支开发管理实践

╰+攻爆jí腚メ 2024-03-31 11:43 4阅读 0赞

**目录**

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修复完成之后，再将开发分支合并到主干，主干发布到测试环境，复测通过之后才算合并完成。
 *  分支删除：通常情况下，没必要删除，如果迭代版本太多，可以制定删除规则进行删除。