git流操作规范

必须要做的

1. 除了master dev分支外，其他分支都需要以 feature fix update开头。
2. pull代码的时候都使用git pull -r，这样可以减少很多不必要的merge提交。
3. 由于合并dev都是扁平化提交，所以需要注意一个版本内的代码需要合理注释，否则有找不回来的风险。如在同一个版本中，添加了某段代码然后直接删了，那么这个分支合并删除后这段代码就找不到了。

绝对不能做的

1. master dev分支绝对不能强制推送！！！否则大家的仓库都会爆炸！

分支定义

master：与线上完全对应，保护分支。

dev：将要发布的下个版本，保护分支。

fix：branch from master，线上bug修复分支，修完后merge回dev master。

sprint: branch from dev，一般是sprint/1.0这种格式。每个迭代一个分支，测试结束后扁平合并到dev并删掉。如果dev分支有更新，sprint需要及时merge dev。不需要进行保护，改动后自动部署到测试环境。

update：branch from dev，基础框架、基础库进行的修复、升级。升级完成后合回dev并删掉。

feature: branch from sprint，正常迭代版本。一个人开发时可以随便强制推送，开发完成后直接merge到sprint分支上。一般是feature/1.0/addMoney。

实际例子

1. 新建文件test.txt，内容为:“我是初始版本！”初始化仓库，新建分支dev，并提交。仓库初始化完成。
2. 从dev分支开新分支sprint/1.0，再新开分支feature/1.0/addMoney，提交2个提交。第一个提交添加内容"0.8\n0.9"，第二个提交修改内容为"0.9\n1.0"，提交。合并到sprint/1.0。
3. 从dev分支开新分支update/db，修改内容我是初始版本！我升级了依赖！，pr扁平合并到dev。然后删除此分支。
4. 分支sprint/1.0需要merge``dev分支并解决冲突。注意：必须使用merge，用rebase会影响feature分支，更麻烦！
5. 分支feature/1.0/addMoney添加提交，添加内容新的内容，合并到sprint/1.0。
6. sprint/1.0开发完成，等待测试。
7. sprint/1.0测试完成，提交pr合并到dev，扁平化合并提交。然后dev合并到master，发布到线上。
8. fix分支操作和update操作类似，只是fix分支是从master分支出来的，然后再合并到dev。

版本发布以后，dev分支会非常干净，只有3个提交：

• init
• !1 update/db
• !2 1.0

这样后续查阅代码改动就会非常方便。