# Git工作流

## 前言

目前的 `Git` 协作工作流的模式非常多，我们主要是借鉴主流的 `Gitflow` 进而构建我们的协作方式。

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


## 工作流

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

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


#### 长期存在分支 或 标签

- `master` | 主分支

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

- `test` | 测试构建分支

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

- `publish`| 发布分支
  
  发行分支即是项目版本可以稳定发行的版本，此发行分支是基于主分支构建而来，主要用于记录版本的节点，必须基于 `master` 分支构建。

> 以上三个分支原则上不允许直接提交代码。


#### 短期存在分支



- `feat` | 功能分支

  功能分支是由无指定版本的需求确立而成，针对无版本的需求 或 功能而建立一个功能分支，好处就是各个功能独立开发则不受影响，同时团队成员之间的协作隔离不容易产生冲突。

- `hotfix` | 修复分支

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

更多细节结合 [分支命名规范](./%E5%88%86%E6%94%AF%E5%91%BD%E5%90%8D%E8%A7%84%E8%8C%83.md) 部分阅读。

## 规范习惯

#### 高频率、细粒度地提交

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

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

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

#### 周期性持续提交

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

#### 分支合并

- 发布分支合并

  发布分支合并必须经过测试组测试，验收通过后才能合并。一般来说是每次迭代上线前一步合并。

- 开发分支合并

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

- 主分支合并

  一般是上线后没出现问题需要回滚，就可以把发布分支 publish 合并到主分支 master，保持主分支的代码同步线上最新的。该操作一般是上线后的次日进行。

#### 禁止直接在 master/publish/test 等合并、发布分支直接提交代码




## 示例


现在已经有了版本 1.0.0 发布版本 ，现在有新的版本规划 1.1.0

那么需要给予发布 1.1.0 新建一个版本开发分支。根据分支命名规范，我们定义为 v1.1.0。

```shell
# 基于 master
git checkout master
# 新建分支
git checkout -b v1.1.0
# 推送远端分支并跟踪
git push -u origin v1.1.0
```


开发完毕，先在本地自测通过，通过后合并功能分支到测试发布分支

**切记千万不要在 test/publish/master 分支直接提交代码， test 分支是合并分支**

```shell
# 推送代码前切记要先 pull 代码
git pull
# 如果有冲突，需要处理冲突再提交
# 没有冲突，可以合并到 test 分支构建测试
git checkout test

git merge v1.1.0

git push origin test
```



测试分支构建完成后，再进行一次自测

所有功能模块完成后，并通过测试验收后，代码可以上线，可以合并到 publish 分支

```shell
git checkout publish

git pull

git merge v1.1.0

git push

```

上线完成后，如果没有回滚问题，**需要将 publish 分支合并到 master 分支上**。




## 线上发现缺陷后仓库操作

- 基于版本标签新建热修复分支，格式为 `{版本标签}_hotfix`，如果没有跟踪版本，就使用 `hotfix` 分支。

- 修复分支同样需要经过自测和测试验收，通过后合并入发布分支上线。

- 修复的提交需要写清楚修复的问题和内容。


## 资料

Git 是一个很好用的工具，熟练掌握 Git 是一个优秀工程师的基本功。

无论是习惯敲命令行还是喜欢用 GUI 工具，都要熟悉 Git 的基本原理、设计思想以及常用命令。

推荐一些学习资料：

- [Pro Git: 详细的 Git 指南，主要介绍了 Git 的使用基础和原理，让你从一个 Git 初学者成为 Git 专家](https://git-scm.com/book/zh/v2)

- [猴子都能懂的 Git 入门：超级简单的 Git 入门，还有 Git 索引](https://backlog.com/git-tutorial/cn/)