代码管理Gitflow规范
git flow的提出者对git flow的介绍：nvie.com/posts/a-suc…
分支功能
master
记录发布历史，不允许直接提交代码，一定是从其他分支merge。
develop
记录开发和集成历史，可以完整体现每个功能的提交和全部的代码历史。
feature
功能分支，用于开发新功能，从develop拉出，开发完成merge回develop。
release
发布分支，临近发布前或集成测试开始后从develop拉出，拉出后本期发布的问题修复都在该分支进行。到达可发布状态后，merge至develop和master分支，同时master分支打上tag，用于生产环境的发布。
hotfix
修复分支，用于线上版本发现问题后的立即修复，基于master上出现问题的tag拉出，修复后合并回master和develop，同时master打上新的tag。
分支开发流程
初始阶段
从master拉出develop。
开发阶段
1.从develop拉出feature。
2.在feature分支上开发。
3.开发结束后merge回develop。
发布阶段
1.从develop拉出release，下一版本的feature完成后可以merge回develop。
2.在release上修复bug并merge至develop。
3.发布节点，merge至master，master上打tag。
维护阶段
1.从master拉出hotfix。
2.在hotfix分支上修复问题，完成后merge回master和develop。如果此时存在release分支，则merge回master和release。
使用准则
1. feature merge回develop时，需关闭fast-foward，保证单个feature合入是一个commit，方便后期revert。
git merge --no-ff
2. feature必须每天rebase develop，保持和develop的最小化差异，后期merge时也能减少conflict
3. git rebase --committer-date-is-author-date develop
上线流程
功能回滚流程
命名规则
分支命名
1.master => master
2.develop => develop
3.feature => branch_{App Name}yyyymmdd_feature{desc}_{version}
4.release => branch_{App Name}yyyymmdd_release{version}
5.hotfix => branch_{App Name}yyyymmdd_hotfix{version}
develop临时发布分支 => branch_{App Name}yyyymmdd_develop{version}
Tag命名
tag_{App Name}yyyymmdd{version}
