经过半年的开发，现在公司内部已逐渐形成比较规范的Git规范，从分支到工作流程到发布打Tag，都形成了一套规范。特此总结下。

Git规范

主要从以下三个方面介绍Git规范：

• 分支模型
• 工作流程
  • Feature(新需求开发流程)
  • Bugfix（Bug修复流程）
• Tag规范

  分支模型

  每个项目都必须要有master、dev分支。
  每个开发人员拥有一个属于自己的分支，如superman。
  如果多人共同开发一个功能，那么可以共享一个分支。

  master分支

  master分支只能存在release版本的代码，并需要对每个release打对应的tag。

  dev分支

  dev分支由master分支checkout，它的作用主要是日常开发合并代码，并与master分支做合并。

  开发人员自己的分支

  开发人员自己的分支，从dev分支checkout，是自己负责的功能分支的上游。

工作流程

开发人员在进行开发或者修复bug之前，必须要先从dev分支上拉取最新的代码。

Feature（新需求开发流程）

当有新需求需要开发的时：

1. 每个开发人员在自己的分支上checkout一个新的feature分支，如在superman的分支checkout；
2. 在新的feature分支上进行开发；
3. 新功能开发完毕后合并到自己的分支；
4. 所有的人员的分支合并到dev分支，并进行测试；
5. 测试通过后，合并到master分支，并打tag（tag示例：REG_20160408_01）。

Bugfix（Bug修复流程）

这里又区分线上的Bug和开发测试阶段的Bug

线上的Bug

1. 开发人员从master分支chekcout一个新的bugfix分支，命名为：dev_bugfix（如有必，可以添加日期后缀dev_bugfix_20160409）；
2. 开发人员在该分支上进行Bug修复；
3. Bug修复后，提交测试；
4. 测试通过后，合并到master分支，并打tag（tag示例：REG_20160409_01，如果是紧急程度非常高的Bug，可用HOTFIX_20160409_01）；
5. 将master分支合并到dev分支，确保dev分支拥有master分支最新的代码。

开发测试阶段的Bug

1. 根据Bug所属的功能分支，分配到对应的开发人员；
2. 开发人员直接在新feature所属的分支上进行Bug修复；
3. Bug修复后，合并到自己的分支上，再合并到dev分支上；
4. 提交测试。

Tag命名规范

格式：前缀_日期_序号

• 前缀：表示项目的各个阶段
  • DEV：表示开发阶段，不可发布线上版本，一般用于开发完成后提测打的tag
  • REG：表示常规发布，可以发布线上版本
  • HOT：表示紧急修复，经测试通过后可以发布线上版本
  • QUICK：表示纯web形式的发布，不涉及db变化
• 日期：一般为当天的日期
• 序号：两位数字，从01开始递增。因为一天内可能会有多个tag。
  示例：REG_20160408_01