2、Git 工作流程

前言

目前的 git 协作工作流的模式非常多，对于我们团队而言，我们借鉴主流的 gitflow 进而构建我们的协作方式。

无论协作的方式再多，作为一个团队协作开发而言，协作必须有一个规范的工作流程。统一协作开发工作流，这样团队之间既可井然有序、高效地协作开发，同时项目开发迭代也会显得井井有序。

工作流

可知，每一个项目的一个端作为一个代码仓库，我们称之为 项目单元。团队开发 与 维护主要是针对项目单元去开发、迭代甚至是维护，使用分支能够有效地避免不同开发工作之间的相关干扰。

一般而言，一个项目单元必须包括如下类型的分支:

长期存在分支 或 标签

• master | 主分支
  主分支属于线上部署的分支，是项目生产稳定运行的项目分支，该分支自能合并 开发分支 或 热修复分支。

• develop | 开发分支
  开发分支 与 主分支必须是并行的，此分支基于运行于开发环境 与 测试环境。同时，从规范上面来说，尽量不要在开发分支上直接做开发，开发分支是由功能分支 或 修复分支合并叠成。

• tag| 发行标签
  发行分支即是项目版本可以稳定发行的版本，可看作为一个版本迭代的分水岭，譬如 1.0.0、 2.0.0等。注意、此发行分支是基于主分支构建而来，主要用于记录版本的节点，必须基于 master 分支构建。

短期存在分支

• feature | 功能分支
  顾名思义，即功能分支，功能分支是由需求确立而成，每一个需求 或 功能就必须建立一个功能分支，好处就是各个功能独立开发则不受影响，同时团队成员之间的协作隔离不容易产生冲突。

• hotfix | 热修复分支
  热修复分支亦称为补丁分支，假设生产分支出现异常等 bug 危急的情况，需要建议一个修复分支，使得主分支合并进而解决 bug，注意、修复分支在主分支合并的同时必须由开发分支也合并，同时发行版也要合并构建成小版本的发行版，测试通过后题需要基于热修复分支打标签。

规范习惯

高频率、细粒度地提交

把大功能的实现尽可能分解成更多的相对独立的小模块，每个小模块测试完成后提交修改，再开始下一模块的开发。这样做能保证每次提交的内容高度相关，方便定为错误、解决合并冲突。

提交之前务必通过自测与单元测试

每次提交代码不要自以为然，必须要将改动的代码进行自测 或者 单元测试，确保开发环境 与 测试环境平稳正常运行，否则会造成持续集成不通过、程序运行失败，甚至影响团队成员之间相互开发协作。

周期性持续提交

经常提交势必让你每次提交的东西都很少，也有助于你只提交相关的改动。并且，你还能更频繁地与别人共享代码。通过这种方式，所有人在集成代码时都会感觉更轻松，也就能避免一些不必要的冲突。相比之下，如果每次提交的东西很多、改动很大、时间间隔很长，那么在代码合并过程中产生的冲突就很难解决了。约定: 在有改动的情况下，至少一天一提交。

分支合并

• 主分支合并
  主分支合并必须经过测试组测试，验收通过后才能合并。一般而言、每次迭代上线前一步合并。

• 开发分支合并
  开发分支合并功能分支，尽量做到“频繁合并”，也就是说尽量将功能需求分解成 N 个功能模块，每一个功能模块完成就提交代码并合并到开发分支，这样可以减少分支合并甚至拉去而造成冲突。

代码提交的姿势

此部分属于团队规范约定，已独立描述约定。

姿势演练

如下部分命名会携带 时间、日期信息 视团队而定，目的是防止过多临时分支存在，谁的谁删除

现在已经有了版本 1.0.0 发布版本，即已经存在 tag1.0.0 ，现在有新的版本规划 1.1.0

那么需要给予发布 1.0.0 新建一个版本开发分支

git checkout -b 1.1.0_develop

这个版本有很多不止一个功能，同时有不止一个人参与这个版本迭代开发

研发 a 需要参与视频模块开发，则需要基于 1.1.0_develop 创建一个功能分。支命名规范 feature/{version}*{function}__{author}*{datetime}

git checkout -b feature/1.1.0_video_a_20200806

研发 b 需要参与朋友圈模块开发，则需要基于 1.1.0_develop 创建一个功能分

git checkout -b feature/1.1.0_friends_group_b_20200805

切记千万不要在开发分支直接提交代码 开发分支是合并分支

开发完毕合并功能分支，处于不断合并的过程

git merge feature/1.1.0_video_a_20200806
git merge feature/1.1.0_friends_group_b_20200805

自测完成后，没有问题那就将功能分支删除

git branch -d feature/1.1.0_video_a_20200806
git branch -d feature/1.1.0_friends_group_b_20200805

提测发现有缺陷，需要基于版本迭代分支创建缺陷修复分支

git checkout -b fix/1.1.0_video_upload_bug_alicfeng_20200808

修复完成再合并到迭代分支

git merge fix/1.1.0_video_upload_bug_alicfeng_20200808

测试通过后 通过约定的方式 tag 即为发布版本 发布 1.1.0 版本

git tag -a 1.1.0 -m "release:version:1.1.0"

线上发现缺陷后 仓库操作与协作约定

• 基于版本标签新建热修复分支
• 开发分支合并热修复分支 主分支合并开发分支
• 基于主分支新建新的版本标签
• 务必在 git上编写更新内容

git checkout 1.1.0
git checkout -b hotfix/video_alicfeng_20200809
git checkout develop
git merge hotfix/video_alicfeng_20200809
git checkout master
git merge develop

# 测试通过后
git checkout hotfix/video_alicfeng_20200809
git tag -a 1.1.1 -m "fixed:video:upload"