### 團隊成員必須強制遵循統一的規范，才能保證協作的效率。誰不嚴格遵守規范，誰就是團隊的敵人。 > 建立完善的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分支上合并就可以了。 所以，團隊合作的分支看起來就像這樣：