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分支管理策略