必须要做的
- 除了master dev分支外，其他分支都需要以 feature fix update开头。
- pull代码的时候都使用
git pull -r，这样可以减少很多不必要的merge提交。 - 由于合并dev都是扁平化提交，所以需要注意一个版本内的代码需要合理注释，否则有找不回来的风险。如在同一个版本中，添加了某段代码然后直接删了，那么这个分支合并删除后这段代码就找不到了。
绝对不能做的
- 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。
实际例子
- 新建文件
test.txt，内容为:“我是初始版本！”初始化仓库，新建分支dev，并提交。仓库初始化完成。 - 从dev分支开新分支
sprint/1.0，再新开分支feature/1.0/addMoney，提交2个提交。第一个提交添加内容"0.8\n0.9"，第二个提交修改内容为"0.9\n1.0"，提交。合并到sprint/1.0。 - 从dev分支开新分支
update/db，修改内容我是初始版本！我升级了依赖！，pr扁平合并到dev。然后删除此分支。 - 分支
sprint/1.0需要merge``dev分支并解决冲突。注意：必须使用merge，用rebase会影响feature分支，更麻烦！ - 分支
feature/1.0/addMoney添加提交，添加内容新的内容，合并到sprint/1.0。 -
sprint/1.0开发完成，等待测试。 -
sprint/1.0测试完成，提交pr合并到dev，扁平化合并提交。然后dev合并到master，发布到线上。 -
fix分支操作和update操作类似，只是fix分支是从master分支出来的，然后再合并到dev。
版本发布以后，dev分支会非常干净，只有3个提交：
- init
- !1 update/db
- !2 1.0
这样后续查阅代码改动就会非常方便。
