Git 工作流程

团队多人协作，必须要有一个适合团队的，规范的工作流程

协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。"工作流程"在英语里，叫做"workflow"或者"flow"，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

市面上主要有3中工作流Git flow，Github flow，Gitlab flow。这里我们采用Git flow工作流。

下面具体介绍该工作流

主要特点

首先，项目存在两个长期分支。

• 主分支master
• 开发分支develop
  前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
  （两个长期分支）

其次，项目存在三种短期分支。

• 功能分支（feature branch）
• 补丁分支（hotfix branch）
• 预发分支（release branch）（可用个人开发分支替代）

日常开发

• 创建个人开发分支，基于远程 dev 创建

  git checkout -b feature-a origin/dev

• 同步 dev 分支

  git rebase origin/dev

• 完成开发，commit，push 远程。
• 发起合入 dev 分支请求（使用 gitlab 新建合并请求）
• 管理者接受合并请求，代码合并进入 dev 分支。

预发布版本测试、正式发版

• 创建预发布分支（如：release-1.0.0），基于 dev 分支创建预发布分支
• 测试预发布分支代码
• 测试通过后，合入 master 分支
• 正式发布版本，打版本 tag

bug 修复

预发布版本 bug 修复

• 创建bug分支，基于预发布版本分支创建。（假设预发布版本分支为：release-1.0.0）

  git checkout -b 15-release-1.0.0-bug-a origin/release-1.0.0

  建议 bug 分支命名规范：与 issue 的名字保持一致，并且以issue的编号起首。如"15-release-1.0.0-bug-a "。
  开发完成后，在提交说明里面，可以写上"fixes #14"或者"closes #67"。Gitlab 规定，只要commit message里面有下面这些动词 + 编号，就会关闭对应的issue。
  如未创建 issue，去掉头部的编号。

• 完成修复 bug ，本地提交（commit），push 远程。
• 发起合入预发布版本分支（使用 gitlab 新建合并请求）。

• 发起合入 dev 分支（使用 gitlab 新建合并请求）。

  注意：bug 修复完成后，同时需要合入 dev 分支

• 管理者接受合并请求，代码合入目标分支。

master（线上） bug 修复

流程同 "预发布版本 bug 修复" 流程

区别在于

• 创建分支是基于 master 分支创建
• 分支名为 15-master-1.0.0-bug-a
• bug 修复完成后，发起合入 master 分支和 dev 分支。

参考：
Git 工作流程
Git分支管理策略