git分支管理

使用git也有半年之久了，之前看过一些别人的分支管理，写的有点抽象，可能每个人理解不一样，自己也总结了一些个人经验，希望对大家有帮助。

一、分支模型

• 每个项目必须要有master、develop、feature、hotfixes、开发者分支。

二、master分支

• master分支只能存release版本（发布到线上的版本），并需要对每个release版本标上tag。 
  一个项目只有一个master分支

三、develop分支

• develop分支起初从master分支检出，他的作用主要是日常开发合并代码，并与master分支做交互，永远都是保持最完整的代码结构。当开发人员比较多时，可指定一个人管理develop分支，专门负责合并代码，便于管理，避免多人同时同时使用develop分支而出现问题。

• 当功能开发完成，提交到feature分支，合并到develop分支上，测试完成后可以合并到master分支发布出来，并打上tag标记。 
  一个项目只有一个develop分支

四、功能分支

• feature功能分支由develop分支检出，主要用于多人一起开发同一个功能，功能开发完成，由功能负责人合并到develop分支，由测试人员测试通过后，总负责人负责合并到master上，再发布到线上。 
  一个项目有多个feature分支，例如：feature/register、feature/login、feature/article分支等等，总之一个功能一个分支

五、开发者分支

• 开发者分支由feature分支检出，以开发者名称命名，当前功能开发完成，由功能负责人负责合并到feature上。 
  一个项目有多个开发者分支，例如：lisa、jack、jason等 
  也可以不要开发者分支，大家在功能分支上开发，每日开发直接提交到功能分支上

六、紧急bug修复分支

• hotfixes紧急bug修复分支，由master分支检出，以版本号拼接日期命名，bug修复完成合并到develop分支拉取测试，测试ok之后，合并到master，上线使用。 
  hotfixes分支有多个，例如：hotfixes/10_20160720、hotfixes/11_20160815

最后

• 规范是死的，人是活的，可以根据实际情况适当调整。