Akira
发布于

Git 流程使用规范

一、分支管理规范

  1. Git Flow 模型
    Git 流程使用规范
    Description

  2. Git Flow 分支说明
    Master

发版分支 + 保护分支。功能代码在 Release 分支上测试通过、或 BUG 已在 Hotfix 分支上修复,则需要将代码合并到 Master 分支。代码合并到 Master 分支,即代表可以随时发版,发版成功时需要基于 Master 分支上的最新提交节点打 Tag。

Hotfix

修复分支 + 临时分支。线上出现紧急 Bug 时,需要基于对应版本的 Tag 创建修复分支,问题修复完成时以此分支进行提测。问题修复后,需将代码合并到 Develop 和 Master 分支。

基于发版 Tag 创建,最后合并到 Develop 和 Master 分支。

Release

预发布分支 + 临时分支。功能开发完成并合并到 Develop 分支时,基于 Develop 分支创建 Release 分支进行提测 。Release 分支上出现影响发版的 Bug 时,需要创建 Feature 分支修改 Bug;当测试通过后,需将代码合并到 Develop 和 Master 分支。

基于 Develop 分支创建,最后合并到 Develop 和 Master 分支。

Develop

开发分支 + 保护分支。多人协作开发时的代码合并总分支,功能分支向 Develop 分支合并时,往往会有 CodeReview 流程。

基于 Master 分支创建。

Feature

功能分支 + 临时分支。有新需求时,基于最新的 Deveop 分支创建功能分支,功能开发完成时,需将代码合并到 Develop 分支。

基于 Develop 分支创建,最后合并到 Develop 分支。

  1. Tag&Branch 的区别
    Tag 和 Branch 类似,都是引用或者说者指针。在工程里 .git/refs 目录下能够清楚的看到,各个 Tag 和 Branch 所指向的提交节点的 SHA-1 值。

区别:

Tag:Tag 的位置是固定的,在给指定提交打好标签以后,它就固定于此位置
Branch:Branch 的位置是会不断变动的,随着分支的向前推移或者向后回滚,都在不断变化
尽量使用 Tag,保存代码片段。

二、Git Commit 提交规范

  1. Commit Message 格式
    ():
    < 空行 >
<空行>
可以看出分为三个部分,头部、主体、底部。

头部

():
type 类型,修改的类型级别:

feat:新功能(feature)
fix:修补 bug
docs:文档(documentation)
style: 格式(不影响代码运行的变动)
refactor:重构(即不是新增功能,也不是修改 bug 的代码变动)
test:增加测试
chore:构建过程或辅助工具的变动
scope 修改范围:

主要是这次修改涉及到的部分,最好简单的概括
subject 修改的副标题:

主要是具体修改的功能点
body:主要对本次 commit 的详细描述,可以分成多行。

footer:主要放置不兼容变更和 Issue 关闭的信息。

为了方便代码的快速提交,body 和 fotter 部分可以省略。

  1. 使用介绍
    需求开发或者修改 Bug 时,提交代码时要添加对应 Jira 编号:

Git commit -m "feat(CHESS-1217): 我的页面增加分享入口及分享功能开发"
修改 Bug 时,需要指明修改代码所在模块:

Git commit -m "fix(分享): 修改修改部分手机分享大图为空问题"
没有具体模块、或者多模块代码一起提交时,可使用其他提交方式:

Git commit -m "fix(BUG): 修改推送红点提示逻辑"
3. 相关工具
Git Hook 自定义拦截脚本:commit-msg

使用环境:python3.7

使用方式:

打开工程目录下的 .git/hooks 文件夹
将 commit-msg 脚本复制到文件夹下,即可
全局设置:通过以下方式,可全局设置,每次 Git clone 时,自动将 commit-msg 脚本添加到工程的 hooks 目录中:全局设置 commit-msg。

其他工具:

Commitizen:辅助撰写合格 Commit message 的工具
Commitlint:Commit message 规则校验工具
4. 拓展
GitLab 与 Jira 关联

效果:Git Commit 时,在 message 里面添加工单号,可在 Jira 对应工单详情页查看到本次提交。

配置:官方文档。

三、代码评审流程

  1. 评审环节
    代码评审发生在 Feature 分支向 Develop 分支合并的过程中:

Git 流程使用规范
(图片来源:ProcessOn 模板)

  1. 代码评审流程
    Git 流程使用规范
    不同的颜色块,代表不同的角色
    创建一个 Merge Request 可以进行多次 Push
    开发人员推动整个代码评审流程的执行,包含及时通知组员评审代码、通知组长合并代码等
  2. 保护分支设置
    在 GitLab 打开要设置的工程 (Maintainers 角色),选择 Setting -> Repository -> Protected Branches:

Git 流程使用规范
将 master 和 develop 分支设置为保护分支,只能是 Maintainers 角色 可以合并请求,并且禁止直接 push 代码。

Git 流程使用规范
通过以上设置之后,所有代码只能通过创建 Merge Request 的方式合并到 develop 和 master 分支;为了代码库的安全,需要回收 Maintainers 权限,除组长外的开发人员都是 Developer 权限。

  1. Merge Request
  2. 创建 Merge Request

打开 Project -> Merge Requests -> New merge request,选择分支创建合并请求:

Git 流程使用规范
选择源分支,需要合并的代码所在的分支
选择目标分支,将最新代码合并到的分支
2. 填写必要信息

Git 流程使用规范
Git 流程使用规范
Title:简单总结本次 Merge 的修改点
Description:详细描述修改内容,影响范围等
Assignee:委托人,选择具有 Maintainers 角色的成员,该成员会收到合并请求的邮件通知,最后由该成员合并请求
Approvers:一般选择小组成员,小组成员具有审核代码权限,对不合格代码可以要求开发者修改
分支选择,功能分支向 develop 分支合并时,会有删除源分支选项,建议勾选
针对本次合并的提交,一次合并请求可以包含多次提交
3. 代码评审及合并请求

Git 流程使用规范
Git 流程使用规范
只有评审成员评审通过时,合并按钮才会高亮,才能合并代码
参与代码评审的成员,认为代码没有问题时,可点击该按钮
针对当前代码创建的讨论,有讨论存在时,开发者需要及时解决
如果代码有问题,可直接创建一个讨论,即 3 列表会增加,开发者修改之后可点击 5 关闭讨论
代码修改之后,或者不需要修改,点击关闭讨论
5. 其他注意事项

  1. 提交合并请求时,先同步最新代码

提交合并代码前,建议先执行 Git fetch 和 Git merge/rebase 将 develop 分支下的最新代码更新到开发分支,再提交合并请求,避免造成冲突。

  1. 合并代码到 master 分支

通过 develop 分支提测且测试通过后,将 develop 分支的代码合并到 master 分支进行发版,版本发布完成时及时打标签。

四、Git 项目集成构建

  1. 简介
    GitLab-CI

GitLab-CI 是 GitLab Continuous Integration(GitLab 持续集成)的简称。

只要在项目仓库的根目录添加 .gitlab-ci.yml 文件,并且配置了 Runner(运行器),那么每一次合并请求 MR 或者 push 都会触发 CI pipeline。

GitLab-Runner

GitLab-Runner 是 .gitlab-ci.yml 脚本的运行器,GitLab-Runner 是基于 GitLab-CI 的 API 进行构建的相互隔离的机器(或虚拟机)。GitLab Runner 不需要和 GitLab 安装在同一台机器上,同时考虑到 GitLab Runner 的资源消耗问题和安全问题,也不建议这两者安装在同一台机器上。

Pipelines

Pipelines 是定义于 .gitlab-ci.yml 中的不同阶段的不同任务。

Pipelines 可理解为流水线,流水线包含有多个阶段(stages),每个阶段包含有一个或多个工序(jobs),比如先购料、组装、测试、包装再上线销售,每一次 push 或者 MR 都要经过流水线之后才可以合格出厂。而 .gitlab-ci.yml 正是定义了这条流水线有哪些阶段,每个阶段要做什么事。

  1. GitLab-CI 功能配置
    GitLab-Runner 安装(macOS)

Install and start gitlab-runner:

brew install gitlab-runner
brew services start gitlab-runner
Register gitlab-runner:

gitlab-runner register
配置以下参数:

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com ):
Please enter the gitlab-ci token for this runner:
Please enter the gitlab-ci description for this runner:
Please enter the gitlab-ci tags for this runner (comma separated):
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
具体配置项的值可参考项目信息(Project -> Settings -> CI/CD -> Runners):

Git 流程使用规范
右侧是创建好的 Runners;对于多项目可以创建 Shared/Group Runners,多个项目可以共享,不用一一创建;不同 Runners 的创建,仅仅是 Token 不同。

添加构建任务

在根目录中创建 .gitlab-ci.yml 文件,具体代码可参照以下示例。

Android 工程:

stages: # 构建步骤

  • build

build job:
stage: build
tags: # 根据 tag,选择执行的 runner
- tag_0.0.1
only: # 只有在列出的分支合并代码时,才会触发构建
- develop
script: # 构建执行的脚本,顺序执行
- chmod a+x gradlew
- ./gradlew assembleDebug
artifacts: # 构建后的产物
paths:
- app_debug/
iOS 工程文件配置类似,只是 script 脚本不同;.gitlab-ci.yml 具体语法,可参考以下官方文档:gitlab-ci 语法。

将代码 push 到远程分支或者合并请求时,就会自动执行脚本:

Git 流程使用规范
点击列表,可看到单个 job 的执行情况,包括控制台日志输出和文件产出:

Git 流程使用规范
3. GitLab + Jenkins 实现 CI 功能
Jenkins 配置

登录 Jenkins 账户,打开“系统管理” -> “插件管理” -> “可选插件”安装以下两个插件:

Git 流程使用规范
打开“系统管理” -> “系统设置” -> “GitLab” 配置 GitLab 服务:

Git 流程使用规范
在 Jenkins 首页,打开“项目”,“配置” -> “构建触发器”配置以下信息:

Git 流程使用规范
打开“高级”,生成 Secret token,配置 GitLab 的时候,需要用到:

Git 流程使用规范
GitLab 配置

打开 Project -> Settings -> Integrattions 填写上一步生成的 URL 和 Secret Token 信息:

Git 流程使用规范
配置完成,当 push 代码或者合并请求时,会自动触发 Jenkins 构建。

评论(1)
  • 小码哥

    这篇文章我之前看到过。 我们现在的分支管理流程就是借鉴的这个。