DEV Community

zerix
zerix

Posted on • Edited on

1

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

背景

常见的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直接可以通过不同分支的配置来进行触发构建。

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (0)

Qodo Takeover

Introducing Qodo Gen 1.0: Transform Your Workflow with Agentic AI

Rather than just generating snippets, our agents understand your entire project context, can make decisions, use tools, and carry out tasks autonomously.

Read full post

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay