一、分支管理规范1. Git Flow 模型

git的基本工作流程（Git流程使用规范）(1)

（图片来源：A successful Git branching model）

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 分支。

3. Tag&Branch 的区别

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

区别：

  • Tag：Tag 的位置是固定的，在给指定提交打好标签以后，它就固定于此位置
  • Branch：Branch 的位置是会不断变动的，随着分支的向前推移或者向后回滚，都在不断变化

尽量使用 Tag，保存代码片段。

二、Git Commit 提交规范1. Commit Message 格式

<type>(<scope>): <subject> <空行> <body> <空行> <footer>

可以看出分为三个部分，头部、主体、底部。

头部

<type>(<scope>): <subject>

type 类型，修改的类型级别：

  • feat：新功能（feature）
  • fix：修补 bug
  • docs：文档（documentation）
  • style： 格式（不影响代码运行的变动）
  • refactor：重构（即不是新增功能，也不是修改 bug 的代码变动）
  • test：增加测试
  • chore：构建过程或辅助工具的变动

scope 修改范围：

  • 主要是这次修改涉及到的部分，最好简单的概括

subject 修改的副标题：

  • 主要是具体修改的功能点

body：主要对本次 commit 的详细描述，可以分成多行。

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

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

2. 使用介绍

需求开发或者修改 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

使用方式：

  1. 打开工程目录下的 .git/hooks 文件夹
  2. 将 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的基本工作流程（Git流程使用规范）(2)

（图片来源：ProcessOn 模板）

2. 代码评审流程

git的基本工作流程（Git流程使用规范）(3)

  • 不同的颜色块，代表不同的角色
  • 创建一个 Merge Request 可以进行多次 Push
  • 开发人员推动整个代码评审流程的执行，包含及时通知组员评审代码、通知组长合并代码等
3. 保护分支设置

在 GitLab 打开要设置的工程 (Maintainers 角色)，选择 Setting -> Repository -> Protected Branches：

git的基本工作流程（Git流程使用规范）(4)

将 master 和 develop 分支设置为保护分支，只能是 Maintainers 角色 可以合并请求，并且禁止直接 push 代码。

git的基本工作流程（Git流程使用规范）(5)

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

4. Merge Request

1. 创建 Merge Request

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

git的基本工作流程（Git流程使用规范）(6)

  • 选择源分支，需要合并的代码所在的分支
  • 选择目标分支，将最新代码合并到的分支

2. 填写必要信息

git的基本工作流程（Git流程使用规范）(7)

git的基本工作流程（Git流程使用规范）(8)

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

3. 代码评审及合并请求

git的基本工作流程（Git流程使用规范）(9)

git的基本工作流程（Git流程使用规范）(10)

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

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

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

2. 合并代码到 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 正是定义了这条流水线有哪些阶段，每个阶段要做什么事。

2. 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的基本工作流程（Git流程使用规范）(11)

右侧是创建好的 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的基本工作流程（Git流程使用规范）(12)

点击列表，可看到单个 job 的执行情况，包括控制台日志输出和文件产出：

git的基本工作流程（Git流程使用规范）(13)

3. GitLab Jenkins 实现 CI 功能

Jenkins 配置

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

git的基本工作流程（Git流程使用规范）(14)

打开“系统管理” -> “系统设置” -> “GitLab” 配置 GitLab 服务：

git的基本工作流程（Git流程使用规范）(15)

在 Jenkins 首页，打开“项目”，“配置” -> “构建触发器”配置以下信息：

git的基本工作流程（Git流程使用规范）(16)

打开“高级”，生成 Secret token，配置 GitLab 的时候，需要用到：

git的基本工作流程（Git流程使用规范）(17)

GitLab 配置

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

git的基本工作流程（Git流程使用规范）(18)

配置完成，当 push 代码或者合并请求时，会自动触发 Jenkins 构建。

,