首先：Git大法好～
獨立開發、一兩人開發、十人協同開發、百人協同開發，Git大法雖好，但得用的好。
獨立開發與人少的時候協同開發，問題不大。人多了就容易出事。
一般開發會約定如下分支:
- master分支：線上分支，不允許隨意提交修改，僅允許develop分支合併，僅管理員操作（一般是開發老大）
- develop分支：開發分支，不允許直接修改，但允許程序員發起pr合併至develop，用於檢出新
feature-名字分支開發新功，也用於合併至master分支。爲什麼不直接從master檢出新分支開發？下文會指出原因- release分支：測試代碼分支，不允許直接修改，但允許程序員發起pr合併至release，用於測試環境使用
feature-名字分支：程序員開發使用的功能分支，從develo上檢出的開發分支
那麼，正常開發流程：
譬如我要開發一個登錄功能
1.首先，從develop上檢出新分支`feature-login`分支至本地，開發
2.完成開發後，push至遠程`feature-login`
3.此時我們需要測試新增的登錄功能，那麼，我們應該發起一個marge request（pr）至release分支（上文所說的測試分支），開發老大（管理員）同意pr，即成功合併至release分支
4.然後走測試流程
5.測試通過後，準備上線，那麼，需要從`feature-login`分支發起pr至develop分支，管理員審覈後，由管理員操作develop分支，合併至master爲什麼不從feature-login分支直接pr至master分支？
原因：
- 1.master分支爲線上生產環境代碼，不應該隨意合併提交，合併前應審覈代碼；
- 2.多人協同，極易出現代碼衝突，故應約定所有人先合併代碼至develop分支，解決衝突後再由develop合併至master。所有人從develop分支檢出feature分支開發，保證了代碼的一致性，這也是爲什麼不直接從master檢出分支的原因。
注意事項：
-
release分支對應測試環境，絕不要將release分支合併至develop或master分支上
- release分支爲測試分支，應於master、develop分離（測試/線上分離）
- release分支上可以放任意測試代碼，代碼混亂，可能今天a程序員pr至release測試功能，下午b程序員也pr了新功能測試，但都不是今天上線的且需要測試的功能，然後c程序員直接將release分支合併至master分支，那麼將會出現不可預估的bug，後果極其嚴重
- feature分支發佈之前，可以先從develop拉去代碼至本地的feature分支，以解決衝突，解決後push feature分支至遠程，然後再請求合併至develop，管理員合併時將無需面臨代碼衝突問題。
- 代碼合併至develop分支後，應刪除遠程端的feature分支。因已合併至develop，後續改動依舊需要從develop分支上檢出代碼（因爲其他人可能在此期間合併了新的功能至develop分支，此操作可保障代碼一致性，極爲關鍵），原feature分支無任何存在的必要。
- 嚴格執行以上流程，Git將是多人協同開發利器