我們之前已經熟悉了git工具（詳情請查看：5分鐘熟悉git工具）
如果是項目是初創期，研發團隊成員只有幾個人，那么git用不好，對項目影響也不會太大。
如果項目已經初具規模，研發團隊在數十人以上，那么項目代碼管理，就是一門非常具有藝術性的工作，處理不好將會帶來災難性的后果。
今天我們通過一些工作需求場景及其對應的解決方案，來快速熟悉掌握在大項目大團隊中如何通過git進行有效的代碼管理。相信聰明的你，看完一定會有收獲！
【正文開始】
初創團隊的工作流程，一般是：
1）業務功能A開發完了，提交測試部門進行測試
2）測試部門測試完了，提交到運維部門進行生產環境部署
看上去工作非常順利，但項目初具規模后，以下新問題會陸續產生：
1）測試部門尚未完成功能A測試，產品就下發了功能B的研發任務；
2）研發人員繼續在master分支上研發功能B，測試部突然告知功能A有缺陷需要整改；
3）有些時候，測試部工作出現問題，導致錯誤沒有被發現，而被提交到了生產環境
.....
可能已經有小伙伴感覺需要開分支進行管理了，但開第2個分支就能解決上面的新問題嗎？答案顯然是否定的。
作者借助自己多年的項目管理經驗，在這里介紹一下分支的設計藝術，有問題或建議的小伙伴，可以在評論區留言互動。
對于一個足夠復雜的項目，我們最少需要 5個分支進行管理，各分支名稱及其適用場景（要解決的問題）說明如下：
1）master 分支
這是主分支，新功能需求的開發工作都需要在此分支上進行；
2）test 分支
這是測試部門使用的分支，當master分支上某個階段性的開發工作結束，合并到test分支進行提測。
3）release分支
這是生產環境使用的分支，當測試部門測試通過后，需要將test合并到release。
4）master_bug 分支
當release 發布以后，需要立即檢出 master_bug 分支
如果生產環境需要緊急消缺，則直接讓研發人員從 master_bug上進行修改
5）test_bug 分支
當release 發布以后，需要立即檢出 test_bug 分支
master_bug修改完畢后合并到 test_bug，最終由test_bug合并到release完成生產環境的缺陷修復
兩個問題答疑：
1、問: 為什么不從master_bug 合并到 test呢？
答：因為當項目足夠復雜時，test_bug（release） 跟 test 功能代碼已經差的很多了，強行合并對relase會影響較大，風險較高。
2、問：為什么用這么多分支管理？用tag標簽管理不行么？
答：真實的項目生產環境部署流程，一般都要經歷研發部，測試部，運維部等多人協作，跨部門協作的效率過來人都懂，經歷一番寒徹骨之后，得出的結論就是要想效率高，人參與的越少越好。現在業界基本都是在使用自動化運維工具（比如jenkins）進行相關工作，而對于這些工具，嚴格的branch分支名稱，相對于隨意性較強的tag標簽，更容易配置。
