在去年的大約這個時候，我的領導讓我研究一下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分支也一定不會有沖突，否則肯定是你發布分支代碼有問題。

以上就是我遇到的問題和解決方案以及git分支的使用心得。

Git分支使用心得