參考資料：A successful Git branching model
在去年的大約這個時候，我的領導讓我研究一下git的使用方法，方便我們自己的代碼管理，因為我們原先使用的是SVN，使用起來沒那么方便，所以讓我研究研究git的使用。我就簡單的研究了兩天，用我的IDE(vs2015)試了下，還不錯，然后開發了一個月之后，整個部門都換成了git進行項目代碼的版本控制。到現在為止已經使用了git接近一年了。
就是因為當初簡單的研究了兩天，這接近一年的時間里只是使用的git的基本功能，沒有把git分支的強大使用起來，在兩個月前發現了我們使用的git分支的問題，所以在分支使用方面進行了改進，把我的心得也給大家分享一下。
關於分支的使用，我從網上找到了一些相關的資料，網上常見的分支使用是分三種：master(主干)、develop（開發）、publish(發布)三種常規分支。而我們根據網上的先進行了一個迭代，而后覺得有點不符合我們的使用場景，所以我們自己又有了其他的使用方式，下面我給大家分享一下。
項目的初始時會默認有一個master分支，也就是我們常說的主干分支，主干分支的代碼與線上運行的代碼是一致的，而且平時開發的代碼不能推送到master分支上去，所以master分支平時是鎖死的，也就是設置成只讀的，任何人都不能推送代碼到master分支上去。
假如我們現在有個學生管理系統的項目【StudentSystem】,我們要開發一個新功能—考試功能。那么我們需要建兩種分支，一個是發布分支，一個是開發分支。
關於開發
發布分支的創建時間也分兩種，一種是開發之前就建好，另外一種是開發完成之后創建開發分支，不管是哪種，發布分支的代碼始終是與master分支的代碼是一致的。
咱們采取第一種，開發之前就開始創建發布分支。
發布分支名為：
studentsystem_v1.0_exam_publish_from_master(0812build) 或者 studentsystem_v1.0_考試功能_發布分支_from_主干(0812創建)
項目名字_版本號_分支狀態_from_從哪個分支創建(何時創建)
總之分支的名字讓人看到后能明白這個分支是做什么的即可。
開發分支：
studentsystem_v1.0_exam_develop_from_publish1.0(0812build) 或者 studentsystem_v1.0_考試功能_開發分支_from_發布分支1.0(0812創建)
網上查到的資料是到這里就完事了，但是我們開發項目，開發這一個功能是需要2個或者大於2個人的，多人在同一個分支下開發的話，肯定會有沖突，而且不好進行代碼審核，所以我們使用了git的pull request,所以就有下面的，
再創建個人的開發分支
從主開發分支創建個人開發分支，命名如下：
studentsystem_v1.0_ls_exam_develop_from_develop1.0(0812build) 或者 studentsystem_v1.0_李四_考試功能_開發分支_from_開發分支1.0(0812創建)
這樣就可以每個人有一個自己的開發分支，每天下班之前提交當天的代碼到服務器上，然后提交pull request使代碼合並到主開發分支上去，就可以方便大家進行代碼審核。
然后第二天早上上班之后首先修改昨天提交的pull request中被別人發現的問題，再提交代碼到服務器上，等待所有的pull request被審核通過后，大家要從主開發分支上拉取代碼合並到各自的開發分支上去。
最后再進行自己今天的開發任務即可。
關於測試
提交測試之前
保證所有的開發人員的代碼已經全部提交到服務器上並全部通過了pull request。然后把主開發分支(studentsystem_v1.0_exam_develop_from_publish1.0(0812build))的代碼拉取到本地合並到最新的發布分支(studentsystem_v1.0_exam_publish_from_master(0812build))【這就是我說開發之前創建可以，開發完成后創建也可以的原因】上去，但是，合並之前一定要保證發布分支上的代碼是與master分支的代碼是一致的，否則測試等於白測。記住：向發布分支上合並代碼是不會有沖突的，如果有沖突說明你發布分支的代碼不與master分支的代碼一致或者你的開發分支代碼有問題。
提交測試后
我們項目的測試是分兩輪：第一次測試和回歸測試。在測試期間不能往測試環境中發布新的代碼（就是說在進行第一輪測試的時候，出現了20多個bug，開發人員修改的比較快，在測試人員還未完全測試一輪的情況下，已經修改了大半，這種情況也不要發布新的測試版本，否則測試人員的第一輪相當於白測，覆蓋了測試人員原先的測試成果。一定要等測試人員完全測試一遍才可以發布新的測試版本。），
如果遇到了阻塞的bug怎么辦？
這樣也不能發布新的測試版本嗎？這樣肯定是可以發布新的測試版本的，但是新的測試版本不是從開發人員正在開發的分支合並到發布分支上去，然后發布到測試環境中，而是從發布分支上打一個修改阻塞bug的分支出來：
studentsystem_v1.0_exam_[block_bug_name(bug的名字) or block_bug_code(bug的編號)] _from_develop1.0(0827build)
修改完成后合並到發布分支上去，然后發布到測試環境中，這樣就不用打斷或者影響測試正在進行的測試了。也就是說發布分支的代碼與測試環境的一致。
重要的：
發布分支權限設置為保護分支【只有管理員才可以推送代碼到服務器上】，這樣保證入口的唯一性，只有本次迭代負責人才可以合並代碼到發布分支上去。
關於發布
發布我們分為預發布和正式發布。
預發布
就是模擬真實發布環境進行發布，執行sql腳本，修改相關的配置，把發布分支的代碼發布到預發布環境中。
說到這想起來一件事：我們每次進行項目的預發布時，總是很順利，速度也很快，也沒有遇到問題，然后在正式發布的時候，總是遇到各種問題，各種不順利，所以這就導致預發布是沒有意義的，正式發布后與測試環境下的功能也不一致，就是測試環境和預發布環境下功能么有問題，正式發布時也有問題。本次迭代結束后，我們經過討論后想到了一個解決方案：就是發布測試環境也需要服務器管理人員（也就是測試人員）輸入服務器密碼，就是說測試服務器、發布服務器、正式服務器的密碼只有測試人員知道，只有在發布測試版本的時候，只有測試人員輸入密碼后才可以發布新的測試版本到服務器上。開發人員使用開發服務器即可，只需要保證開發服務器上的數據庫數據和數據庫結構與正式的一致即可。
正式發布
正式發布的時候可以是發布分支代碼，也可以把發布分支的代碼合並到master分支上，然后進行發布，注意：從發布分支合並到master分支也一定不會有沖突，否則肯定是你發布分支代碼有問題。
發布完成
發布完成之后，master分支的代碼就是我們本次迭代發布的代碼了，那么需要打出一個tag在服務器上，用項目名稱及本次迭代版本號作為tag的名字，本次發布內容作為tag描述，方便下次代碼出現問題時可以直接在tag的基礎上打出分支進行修改；本次迭代的發布分支及個人的開發分支都可以刪除掉，主開發分支需要保留，方便以后查詢及找回代碼使用，設置主開發分支的開發權限為只讀權限，這樣誰都無法刪除和推送代碼。
發布之后出現bug
如果在開發中或者發布之后線上的程序出現bug怎么處理？按照我的經驗來說的話，先保存自己的開發代碼，然后從master分支打出一個臨時修改bug分支：
studentsystem_v1.1_emegencydebug_from_master(0814build)【緊急bug修復分支】
如果不是很緊急，可以跟本次迭代發版，那么也可以從正在開發的分支上直接修改。
以上就是我遇到的問題和解決方案以及git分支的使用心得。