DEV Community

zerix
zerix

Posted on • Edited on

如何设计适合持续集成的代码分支管理体系

背景

常见的Git开发流程中,建立好分支管理和发布规则,以及良好的日常开发分支管理,能够较大提高开发人员效率,降低沟通维护成本,便于各个项目的codeReview,提供整个产品质量。

分支管理配置

首先,有几条规则需要确定。

  1. dev/master分支不允许直接push,向这两个分支合并代码需要提交MR或者PR。
    所有release分支以 release#VERSION-日期 来命名,比如release#4.0-20221212 表示2022年12月12日发布的4.0分支。relase开头的分支同样不允许直接PUSH,必须提MR来合并代码。

  2. 客户定制需求相关分支以  project#客户名称#VERSION-日期 来命名,比如 project#xinjiangkashi#4.0-20221212,表示新疆喀什的客户分支,project开头的分支不允许直接PUSH,必须提MR来合并代码。

  3. 新功能开发分支为 feature#原始分支名#新增功能说明,比如 feature#dev#added-spark-locality-support ,表示新功能开发,从dev分支checkout出来,新功能是增加 spark locality功能。

  4. bug修复分支以 bugfix#原始分支名#修复BUG说明,比如 bugfix#release#4.0-20221212#fix-null-point-bug。

  5. hotfix分支,一般仅仅作为 release或者project 分支发布后,出现了问题,需要紧急修复,可以创建该分支,创建规则一致。

  6. feature/bugfix/hotfix提交到了一个分支后,如果该功能需要提交到其他分支,可以在页面上操作 cherry-pick 到其他即可。

  7. dev/master/release*/project*开头的分支在git/gitlab服务端配置成保护分支,其他人就不能直接push。

GIT workFlow示例:

Image description

日常开发流程

本文以dev为主要开发分支来介绍,dev分支内包含测试过可以上线的最新代码,根据不同情况,也可以使用master分支来做为开发主分支,遵循策略一致。

新功能开发流程

1.从dev分支checkout出来feature分支,checkout命令:

git checkout -b feature#dev#added-locality-support
Enter fullscreen mode Exit fullscreen mode

说明:feature表示新功能开发,第一个#和第二个#之间内容为checkout原始分支名称,如果是从master分支切换出来,则为feature#master#,最后一部分内容为feature具体新增功能。

2.编写代码,完成测试,测试完成后提交代码到本地,命令:

git commit -am "added locality function."
Enter fullscreen mode Exit fullscreen mode

3.提交代码到远程。

git push origin feature#dev#added-locality-support
Enter fullscreen mode Exit fullscreen mode

4.进行CI构建,测试,测试通过后,提交MR/PR merge到dev分支,相关人员review后最终merge到dev分支。

此处可以配置仓库权限,只有仓库的maintainer可以merge,其他开发人员提交MR后,maintainer需要进行codeReivew,通过后才可以merge到分支,提MR的分支必须要保证可以编译通过,可以正常运行。

在此条件下,dev分支任何时候去构建,都是正常可以编译通过,并且可以发布正常运行的。

5.确认该分支是否需要 cherry-pick 到其他分支,如果需要,则操作 cherry-pick 流程到其他分支。

bug修复流程

BUG修复流程和上述开发流程一致,仅仅是分支名称不一样而已,但是bug的修复要注意提交到release分支后,也需要cherry-pick到dev分支。

Release分支管理

  1. 每周从dev分支checkout出来release分支,如果发布到预发布环境,可以在分支名称末尾增加 -rc 字样来表示,预发布环境测试通过后,从rc分支再checkout出正式分支,发布。(此处相当于release包含两个分支,-rc为预发布环境分支,不带-rc为生产环境分支,上生产后,两个分支内容应该一致。)

  2. 对project分支,如果不想维护太多project分支,对每个客户可以只使用一个project分支,在每次发布后,增加tag来标识此次发布行为,tag仅仅做标识,不和CI结合。

  3. 对于 一个分支是否需要向多个分支进行cherry-pick,需要根据业务场景来确定,比如有些定制化内容,不需要进入dev分支,则不需要cherry-pick到dev,比如一个bugfix需要更新多个project分支和release,则需要逐个cherry-pick。

  4. CI可以根据不同的分支来进行相应的构建,推荐使用gitlab CI直接可以通过不同分支的配置来进行触发构建。

Top comments (0)