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