相信大家在使用Git的过程中，都有一套适合自己公司的流程规范，此处分享的也只是我根据这几年使用Git的经验，总结的一套流程规范，Git功能强大，但仅仅是一个工具，怎么使用，我觉得的没有什么最佳实践，只有最合适的。
Git流程规范.png
1、共设5个分支及Master的若干上线标签，各分支及标签的含义如下：
Master主干分支，只接受Release分支和HotFix分支的合并请求，只能由版本管理员负责合并，合并以后打出一个标签，生产环境直接发布此标签的版本，发布完成需要将Master分支代码合并到所有的Dev、Feature分支上；
Dev开发分支，开发人员将此分支拉取到本地，然后进行功能开发，经过本人单元测试后合并到Dev分支，如果按正常迭代开发，原则上只需要一个Dev开发分支即可；
Feature开发分支，此分支的目的是开发之前，已经明确该分支的代码功能和Dev分支的代码功能不是同一个版本上线，所以需要单独拉出一个分支来管理，同样的道理，负责该分支代码开发的人员，将此分支再往本地拉取一次，继续开发；
Release测试分支，开发环境验证没有问题后，由版本管理员负责，具体的开发人员协助，将各自开发的代码合并到release分支进行测试，测试有问题的，仍然从Dev上修改然后合并到Release分支，直到测试完成，然后将Release分支的代码由版本管理员合并到Master分支；
HotFix解决线上bug的分支，当生产环境出现Bug, 直接从上一次发布的标签版本打出一个HotFix的分支，由负责这个Bug的开发人员拉取到本地，进行代码修改，修改完成以后发布到测试环境验证，验证通过后合并到Master分支，并打出一个上线的标签版本，同时由版本管理员将此标签版本合并回所有的Dev，Feature分支上。
2、注意事项：
所有上线版本都是从Master中打出的标签版本；
如果Dev和Feature两个分支不同期上线，但同期测试，需要打出一个同时包含Dev和Feature代码的Release分支出来用来测试，但往Master合并的时候就需要特别注意不能将Release分支的代码全部合并到Master分支，需进行选取；
HotFix分支的代码需要测试的时候，如果测试任务不紧急，可以在测试环境发布HotFix分支的代码，快速测试完成后，再切换为Release分支供测试，如果测试任务紧急，可以合并到Release分支，测试通过后，有选择的合并到Master;
3、各分支命名规范(禁止出现中文命名)
Master分支和Dev分支名字就是Master、Dev
Master分支打出的标签命名规范：项目名称-release-年月日格式的上线时间
Feature分支，命名规范：项目名称-feature-功能模块名称
Release分支，命名规范：项目名称-releaseTest-年月日格式的上线时间
HotFix分支，命名规范：项目名称-hotfix-年月日格式的上线时间
4、提交代码的注释规范
功能模块-详细功能-说明你干了什么，是开发了什么代码，还是修复了什么问题
