Git分支管理规范实践
问题：
合并代码时候容易出现冲突
解决方法：
通过同一文件对比进行代码合并
1.代码块只有自己修改：合并以自己代码为准
2.代码块非自己修改：合并以对方代码为准
3.代码块中既有自己修改又有别人修改：和对应的提交人协商后解决
避免或减少冲突方案：
1.命名规范：
hotfix_xxx:hotfix_年月日(yyMMdd)_简描述（如：hotfix_200907_fixmeeting）
tag:tag_vm.n.x.y
m.n:项目大版本(如：OA2.1)
x:冲刺版本
y:bug修复等小版本
2.分支管理：
1、dev:作为主要开发分支，所有新需求都在该分支进行开发，小步慢跑的方式。
1.【推荐】主动修改方：如一个小功能开发完毕就应该把代码提交上去，避免积累大量新增或修改代码容易冲突
2.【推荐】被动修改方：每次commit提交后，pull一下线上代码，把最新的代码拉取下拉，避免一次拉取很多文件产生大量冲突
3.【强制】每次push代码之前，要求必须先pull代码，如有冲突解决完冲突后才允许push代码到远程仓库
2、master:作为主要发布分支，记录生产最新代码
1.【强制】禁止直接修改master分支代码，如修复线上bug必须新建hotfix_xxxx分支。
2.【强制】每次master发版后必须打tag，方便代码回滚
3.【强制】hotfix_xxxx分支合并到dev
3、pre:发版辅助分支，承担需求发版前的封版任务。
1.【强制】封版前准备：对比pre分支代码和master分支代码是否一致，确保发版时pre分支代码合并master后，pre和master代码也是一致的。
2.【强制】封版：把本次发版的需求从dev分支代码合并到pre分支，dev分支可以开始开发非本次发版的其他需求
3.【强制】封版后：测试发现pre分支存在bug，直接修改pre分支进行bug修复，修复后把pre中的修复代码合并到dev分支
4.【强制】测试通过：合并pre分支到master分支，并对比pre分支和master分支代码，确保两个分支代码一致。
避免在封版期间其他人对mater代码进行修改，
如存在差异则把master分支最新代码合并到pre，再次进行复测pre。
4、hotfix_xxx:bug修复分支
1.【强制】生产系统发现bug，先从master拉取新的分支（命名：hotfix_xxxx）
2.【强制】hotfix_xxxx分支进行bug修复，测试通过后，hotfix_xxxx。
3.【强制】对比hotfix_xxxx和master分支代码是否一致。
避免在bug修复期间其他人对mater代码进行修改，
如存在差异则把master分支最新代码合并到hotfix_xxxx，再次进行复测。
4.【强制】合并hotfix_xxxx代码到dev分支
5.【强制】master发版，打tag。
6.【强制】删除hotfix_xxxx分支
3.【推荐】commit message格式：<type>(<scope>): <subject>
type(必须):
用于说明git commit的类别，只允许使用下面的标识。
feat：新功能（feature）。
fix/to：修复bug，可以是QA发现的BUG，也可以是研发自己发现的BUG。
fix：产生diff并自动修复此问题。适合于一次提交直接修复问题
to：只产生diff不自动修复此问题。适合于多次提交。最终修复问题提交时使用fix
docs：文档（documentation）。
style：格式（不影响代码运行的变动）。
refactor：重构（即不是新增功能，也不是修改bug的代码变动）。
perf：优化相关，比如提升性能、体验。
test：增加测试。
chore：构建过程或辅助工具的变动。
revert：回滚到上一个版本。
merge：代码合并。
sync：同步主线或分支的Bug。
scope(可选):
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
例如在Service，可以是dao,entity,mapper,xml,yml等。如果你的修改影响了不止一个scope，你可以使用*代替。
subject(必须):
subject是commit目的的简短描述，不超过50个字符。
建议使用中文（感觉中国人用中文描述问题能更清楚一些）。
结尾不加句号或其他标点符号。
根据以上规范git commit message将是如下的格式样例：
fix(dao):用户查询缺少username属性
feat(controller):用户查询接口开发
