项目开发中git分支规范

最近做新项目，团队需要用git来做代码版本控制。因此我们自己制定了一套git分支管理规范。

目的：为了规范代码库分支管理和版本管理，使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条，并避免由于维护造成的错误的版本发布等问题。

1、主分支master

master分支有且仅有一个，用于存储正式发布的历史，在版本库初始化时自动生成。master分支是所有开发活动的核心分支，所有的开发活动产生的输出物最终都会反映到主分支的代码中。

2、开发分支develop

develop分支有且仅有一个，develop分支用来分布重大版本，是所有功能的集成分支。当develop分支上的代码已实现了软件需求说明书中所有的功能，通过了所有的集成测试后，且代码已经足够稳定时，就可以将develop合并到master分支进行发布。

注：master和develop分支的权限需要限制。

3、功能分支feature

feature分支会有很多个，功能分支是为了开发某种特定功能，从master分支上面分出来的。开发完成后，并经过test分支测试后，最终合并到develop。

feature分支命名规范：feature_${Author}_${yyMMdd}_${功能名称}

注意：feature分支要定期合并master的代码（一般一周一次）

4、测试分支test

feature分支会有很多个，并与feature分支一一对应，feature开发完成后需要从fork一个同名的test分支来进行测试。提测时需要告知测试人员专门的测试分支名称和版本。测试阶段如果发生代码改动，需要在feature分支进行修改之后再合并到test分支，然后同步告知测试人员在新版本之上进行测试。

test分支命名规范：同feature，test_${Author}_${yyMMdd}_${功能名称}

5、修补分支bugfix

bugfix分支会有多个，系统日常维护难免会存在bug，这时就需要创建一个分支，进行bug修补。bugfix分支是从master分支上面分出来的，在对bug修补之后，要先合并到develop分支进行测试，测试通过后再合并进master分支，最终发布master分支。

bugfix分支命名规范：bugfix_${Author}_${yyMMdd}_${补丁名称}。