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

你可能感兴趣的:(git实战应用,git,分支管理策略,代码管理规范,分支创建合并流程)