git 协作工作流方案

团队协作开发过程中，git 必不可少，由于我之前使用的都是 SVN 作为代码管理工具，所以在切换成 git 的分布式版本管理工具之后，多少还是需要习惯的过程。另外由于最近两周 git 分支管理和协作上出过几次问题，所以也趁这个机会梳理一下 git 协作的工作流程

定义分支和使用原则

我们主要的分支类型会有 4 个，分别是：master、release、feature、hotifx，另外还会有一个不常用的 dev 分支，下面分别介绍一下分支的定义和使用规则

master 分支：生产主分支

master 分支代码始终保持与生产环境代码保持一致
上线分支始终从 master 分支拉取
上线后需及时将上线分支合并至 master 分支，合并代码时需要打一个 tag 标记当前版本

release 分支：每个上线版本分支

release 命名原则：release-版本号-上线日期，例如 release-v2.6.0-20220715 表示在 2022 年 7 月 15 日上线的 2.6.0 版本
版本号定义原则 x.y.z
- 主版本 x：项目大版本升级或者是有 breaking change 的内容
- 次版本 y：日常迭代或者新增功能
- 修订版本 z：通常是 bug 修复
当上线计划发生变化，有需求无法在该版本上线时，将 git 本地及远程 release 分支删除，重新基于 master 分支拉取新的 release 分支，将需上线的 feature 需求分支合并至新的 release 分支
测试验证完成后，运维将测试环境已经过测试的程序包直接发布至准生产及生产环境
发布完成后由开发负责人将 release 分支代码合并至 master 分支
禁止将 release/xx 分支代码反向 merge 到 feature/xx 分支

feature 分支：功能开发分支

命名参考：feature/功能 xxx
测试时将 feature 合并到需要上线 release 分支中进行发布测试
测试环境出现 bug 时在 feature/xx 分支修复后提交 merge request 到对应的 release 分支
feature 分支开发完成后，开发人员提交 Merge Request 给到管理人员，管理人员检查代码后进行 Merge 操作

hotfix 分支：生产 bug 修复分支

命名参考：hotfix-v1.2.3-20221026（版本号定义同 release 分支）
从 master 直接拉取，修复通过测试并上线后直接合并到 master 分支

dev 分支：测试用分支

使用场景：多条 release 分支需要并行测试时使用，创建 dev 分支并将需要测试的 release 或者 hotfix 分支合并到 dev 分支进行测试
使用完成后即可删除，下次需要使用时再通过 dev 创建即可

工作流场景

在确定好分支和使用原则之后，下面来看在这个 git 工作流程下的开发场景示例

场景一：项目初始化

假设我要已经在本地开发好了项目的第一个版本，此时我需要将项目在 github 做初始化

git init # 初始化 git 仓库
git add . # 把文件提交至暂存区
git commit -m "project init" # 将暂存区文件提交至本地分支
git branch -M master # 当前分支重命名为 master 分支
# 连接 git 仓库，此时连接的是我的演示仓库
git remote add origin https://github.com/wujieli0207/git-flow-demo.git
# 标记 tag 并将代码提交至远端仓库
git tag v0.0.1
git push -u origin master
git push origin --tags

经过以上的操作之后，可以看到我们的项目项目已经初始化完成

场景二：短期迭代

现在 master 分支代码正在生产环境运行，我们收到一个两周之后的要上线的需求，需求可以被拆分为两个开发任务并由两个不同的同事开发，这个时候需要创建三个分支，分别是 release-v0.1.0-20221019、feature/task-a、feature/task-b

当两个 feature 分支开发完成后，将代码合并到 release 分支进行测试，测试完成后将 release-v0.1.0-20221019 这个分支代码发布至生产环境，发布完成后将 release 代码合并至 master 分支，并且删除两个 feature 开发分支

# 需求开发前创建需要的分支
git checkout -b feautre/task-a master
git checkout -b feautre/task-b master
git checkout -b release-v0.1.0-20221019 master

# 需求开发完成后合并 feature 代码
git checkout release-v0.1.0-20221019
git merge --no-ff feautre/task-a
git merge --no-ff feautre/task-b

# 测试完成后发布合并 release 代码
git checkout master
git merge --no-ff release-v0.1.0-20221019

# 标记此次版本为 0.1.0
git tag v0.1.0
git push origin master
git push origin --tags

在这次发布完成后，可以看到此时的工作流

场景三：长线项目和短期迭代场景并行

接下来我们收到了一个项目需求，开发周期是两个月但上线时间暂不确定，另外还有常规的每两周上线的迭代任务

在这个场景下，对于项目需求会创建一个 release-v1.0.0 的分支作为上线分支，在上线时间最终确认后将分支名称修改为 release-v1.0.0-[上线日期]，对于常规迭代版本同样还是按照上线时间 release 分支。除此之外还需要解决两个 release 分支在同一个环境进行测试的问题，这个时候就需要创建一个 dev 分支，然后将两个 release 分支分别合并进入 dev 分支，再将 dev 分支发布至测试环境进行测试

# 创建待上线的分支
git checkout -b release-v1.0.0 master
git checkout -b release-v0.2.0 master
git checkout -b dev master

在测试过程过程中需要将两个分支合并进入 dev 分支进行测试（这里为了演示简化了分支，开发过程中一定是按照在 feature 上开发，然后再合并进入 release 的过程进行的）

# 合并两个 release 分支进入 dev 分支
git merge --no-ff release-v0.2.0
git merge --no-ff release-v1.0.0

当迭代任务和项目任务上线之后，再分别将上线的 release 合并进入 master 并标记 tag，注意 release 分支上线前修改分支名为发布日期

# 合并迭代任务的 release 分支
git checkout release-v0.2.0
git branch -m release-v0.2.0-20221120
git checkout master
git merge --no-ff release-v0.2.0-20221120
git tag v0.2.0

# 合并项目任务操作类似，就不再演示

此时的工作流如图所示，dev 分支如果不再使用的话可以直接删除，后续需要的时候从 master 直接再拉取

场景四：生产 bug 修复

现在在生产运行过程中出现了 bug 需要紧急修复，这个时候就需要使用到 hotfix 分支，我们从 master 分支创建一个 hotfix-v1.0.1-20221106 的分支，在本地修复后并发布上线后，直接合并到 master 分支

git checkout -b hotfix-v1.0.1-20221106 master
# 修复 bug 后发布 hotfix 后
git checkout master
git merge --no-ff hotfix-v1.0.1-20221106
git tag v1.0.1

场景五：某些需求推迟上线

对于需求推迟上线主要会分为两种处理情况

release 中某个 feature 推迟上线。这时只要重新创建一个新的 release 分支，把需要上线的分支合并进入新分支并作简单的回归测试即可
feature 中的某个需求点推迟上线。这个时候就需要使用到 git cherry-pick <commitId> 这个命令，把单独需要上线的分支拿出来放入新的 feature，在把 feature 合并入上线 release 分支进行相同的流程

场景六：生产回退版本

当上线版本发生重大问题的时候，我们往往先要会退到上一个发布版本，由于我们采用的是 docker 部署的镜像发布，所以只要把上一个版本打包的镜像重新在发布一遍就好。而对于生产环境的代码，这个时候我们每次上线后标记的 tag 就可以派上用场了，比如我们要会退到 v1.0.0 版本可以这样操作

git show v1.0.0 # 查看 v1.0.0 版本的 commitId
git reset --hard <commitId> # 会退到指定版本

一些工作流使用经验

统一的 commit 提交规范

对于 commit 的信息在团队使用统一的规范。目前比较通用的规范是采用 Angular 的提交规范格式，然后使用 husky 和 commitlint 对代码进行提交前规范检查，这样能够最大程度保证代码一致性。另外在 code review 的时候，也能根据 header 信息快速信息筛选，比如 style、docs 的 header 的提交信息在合并代码的时候检查一下就可以了，在 code review 的时候就可以直接跳过，提高效率。同时附上我们使用的 commit header

  - feat ：feature，新增功能，能够让用户觉察到的变化
 - fix：bug fix，修复 bug
  - style ：代码样式调整，对逻辑无影响，比如为符合 eslint 要求修改代码格式
  - docs：文档、注释更新
  - refactor：重构（不包括 bug 修复、功能新增），如文件、变量重命名、代码抽象为函数，消除魔法数字
  - perf ：性能提升
  - test：添加、修改测试用例
  - build ：构建流程、外部依赖变更（如升级 npm 包、修改 webpack 配置等）
  - chore：对构建过程或辅助工具和库的更改（不影响源文件、测试用例）
  - ci：修改 CI 配置、脚本
  - revert：回滚 commit
  - wip：开发中
  - mod：不确定分类的修改
  - types：类型修改

另外对于 commit 的颗粒度，我建议还是在 feature 功能模块下，每完成一个具体的功能点（比如：查询）就提交一个 commit，这样在 code review 的时候不会有一个 commit 改动特别多就不想看的情况，另外如果发生需要代码会退或者 cherry-pick 的时候，也能做到精准操作

merge 添加 —no-ff 参数

git merge 命令中使用 --no-ff 参数目的是让提交纪录更清晰。--no-ff 含义是禁止快进式合并，如果我们没有使用这个参数的话，git 在合并分支时只是简单的把指针移动到下游分支，比如下图左侧的效果，release 分支在 master 分支的下游，所以直接移动 master 指针指向 release

而如果使用了 --no-ff 这个参数，git 会生成一条新的提交纪录，这样就有一个清晰的 commit 历史纪录，可以更好的进行代码溯源和版本回退这些场景

尽量不使用 git revert 命令

为什么没有使用 git revert 命令，在最初制定分支和使用原则的时候，对于要上线的 release 分支，要求是重新创建一条新的 release 分支而不是在原有的 release 分支上使用 git revert 命令回退，原因有如下两点

release 分支并没有上线，重新创建 release 分支可以保证提交纪录更简单，而不是混入一个 revert 纪录
git revert 分为两种情况：一种是常规的 commit，这个就是正常的回退。第二种是 merge commit，这种情况下 merge commit 会包含两个 parent commit，代表该 merge commit 是从哪两个 commit 合并过来的，所以在合并的时候需要加上 -m 选项以代表这次 revert 的是一个 merge commit，很容易操作不当导致代码被覆盖的情况

基于以上这两点原因，并且还有一次 revert merge commit 操作导致了代码的丢失的惨痛教训，所以原则上就不再使用 git revert 这个命令了。但其实只要操作足够清晰，git revert 这个命令也是可以正常使用的

以上就是我们现在使用的 git 协作规范和流程，当然还有很多复杂的场景没有考虑到，所以还有相当大的提升空间