开发规范之git flow模型

开发规范算是修养，既然是规范了，当然没多大技巧，但是学习后，能让你更快融入团队合作开发和更好管理团队项目，这个是属于内功，因为和语言无关，通用型。

在不同的开发团队，不同的文化，不同的项目背景情况下规范都有可能需要进行适当调整。

现在git已然是最火的开发合作工具了，但是git极具特色的branch模式，乱拉分支，随意rebase也很常见，先看看这个规范：git flow。

主分支 主分支是所有开发活动的核心分支。所有的开发活动产生的输出物最终都会反映到主分支的代码中。主分支分为master分支和development分支。

• master分支 master分支上存放的应该是随时可供在生产环境中部署的代码（Production Ready state）。当开发活动告一段落，产生了一份新的可供部署的代码时，master分支上的代码会被更新。同时，每一次更新，最好添加对应的版本号标签（TAG）。

• develop分支 develop分支是保存当前最新开发成果的分支。通常这个分支上的代码也是可进行每日夜间发布的代码（Nightly build）。因此这个分支有时也可以被称作“integration branch”。 当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的测试后，并且代码已经足够稳定时，就可以将所有的开发成果合并回master分支了。

仅在发布新的可供部署的代码时才更新master分支上的代码

辅助分支 辅助分支是用于组织解决特定问题的各种软件开发活动的分支。 辅助分支主要用于组织软件新功能的并行开发、简化新功能开发代码的跟踪、辅助完成版本发布工作以及对生产代码的缺陷进行紧急修复工作。 这些分支与主分支不同，通常只会在有限的时间范围内存在。注意定期清理。 辅助分支包括：

1. 用于开发新功能时所使用的feature分支
2. 用于辅助版本发布的release分支
3. 用于修正生产代码中的缺陷的hotfix分支

• feature分支 feature分支（有时也可以被叫做“topic分支”）通常是在开发一项新的软件功能的时候使用，这个分支上的代码变更最终合并回develop分支或者干脆被抛弃掉（例如实验性且效果不好的代码变更）。 使用规范：
  1. 可以从develop分支发起feature分支
  2. 代码必须合并回develop分支
  3. feature分支的命名可以使用除master，develop，release-*，hotfix-*之外的任何名称

feature分支代码可以保存在开发者自己的代码库中而不强制提交到主代码库里。

• release分支 release分支是为发布新的产品版本而设计的。在这个分支上的代码允许做小的缺陷修正、准备发布版本所需的各项说明信息（版本号、发布时间、编译时间等等）。通过在release分支上进行这些工作可以让develop分支空闲出来以接受新的feature分支上的代码提交，进入新的软件开发迭代周期。 当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能，并且已通过所有测试时，我们就可以考虑准备创建release分支了。而所有在当前即将发布的版本之外的业务需求一定要确保不能混到release分支之内（避免由此引入一些不可控的系统缺陷）。 成功的派生了release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。所谓的“下一个版本”是在当前即将发布的版本之后发布的版本。 使用规范：

  1. 可以从develop分支派生
  2. 必须合并回develop分支和master分支
  3. 分支命名惯例：release-*

• hotfix分支 当生产环境中的软件遇到了异常情况或者发现了严重到必须立即修复的软件缺陷的时候，就需要从master分支上指定的TAG版本派生hotfix分支来组织代码的紧急修复工作。 这样做的显而易见的好处是不会打断正在进行的develop分支的开发工作，能够让团队中负责新功能开发的人与负责代码紧急修复的人并行的开展工作。 使用规范：

  1. 可以从master分支派生
  2. 必须合并回master分支和develop分支
  3. 分支命名惯例：hotfix-*

参考资料： 基于git的源代码管理模型——git flow git-flow 备忘清单