### 团队成员必须强制遵循统一的规范，才能保证协作的效率。谁不严格遵守规范，谁就是团队的敌人。 > 建立完善的github版本控制工作流，做好BUG的缺陷跟踪，规划项目成员，组建团队，以及为团队内开发习惯定制标准，成员必须强制遵循统一规范。 规划一套完整的工作流，这样大家的效率都会有所提交。 master，dev这两个分支是必须的，master为最稳定的，用于线上环境。dev 用于开发的，是最新的，也是不确定的，主要用于测试，调试，开发新功能的。 鼓励多拉分支修复问题。 修复问题，增加功能鼓励拉分支，虽然一般从master上拉分支，但是也可以从dev上拉分支进行开发，其它分支完成后（小问题修复后，新功能完成后）先合并到dev上面去，测试好后，在考虑合并到master上面去。 即分支管理遵循一个原则，master用作稳定版代码代码发布，dev用作开发。进行任何分支操作时先想一下这个原则，没有特殊情况的话，master一般只与dev合并，其它分支与dev合并。 团队协作开发时，多使用缺陷跟踪系统，谁完成某个分支后，想合并的话，请先发出一个合并请求，让大家都来校对一下代码，然后再决定考虑是否合并。 任何时候，出来做好问题记录外，还要进行更深入的需求分析，讨论记录将要做的功能，想要解决的问题，提前做好项目发展规范，将为协作，项目的发展带来很大的帮助。最好以问题系统做好标签：即将要做的，或下一版本要做的，正在做的事。 ### 分支策略 在实际开发中，我们应该按照几个基本原则进行分支管理： 首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活； 那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本； 你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。 所以，团队合作的分支看起来就像这样：