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