gitlab 作為版本控制器，基本使用和github 相同，以下是一些策略和介紹：
Git 分支管理策略可以參考下面三個鏈接：
http://www.ruanyifeng.com/blog/2012/07/git.html
http://www.ituring.com.cn/article/56870
http://nvie.com/posts/a-successful-git-branching-model/
本文也是根據以上三個鏈接內容作出的一些總結。
為什么用Git？
Git真的改變了開發商認為合並分支的方式。從經典的CVS/Subversion世界我來自，合並/分支一直被認為是一個有點嚇人（當心合並沖突）和你只是偶爾做的事情。
但使用Git，這些行動是非常便宜和簡單的，他們被認為是一個您的日常工作流程的核心部分，真的。
由於它的簡單性和重復性，分支和合並不再是害怕。版本控制工具應該協助分支/合並比其他任何東西。
足夠的工具，讓我們的發展模式。我將在這里提出的模型基本上是一組程序，每個團隊成員都必須遵循，以來管理軟件開發過程中。
分散而集中
我們使用的存儲庫設置和這個分支模型很好地工作，這是一個中心的“真實”回購。請注意，這是只考慮回購是中央（因為Git是一個軟件，有沒有這樣的東西作為在技術層面中央回購）。我們將把這個回購的原點，因為這個名字是所有Git用戶熟悉。
每一個開發人員pull，push到origin。但除了集中的pull和push關系，每個開發人員也可能從其他同行pull變化，形成小組。例如，這可能是有用的工作，與兩家或更多的開發人員在一個大的新功能，在推動工作之前，過早地。在上圖中，有alice和bob、alice和david，david和clair。
從技術上講，這無非意味着alice定義了一個git遠程，叫bob，指着bob的庫，反之亦然。
主要分支¶:master branches
在核心的發展模式，極大地鼓舞了現有的模式。中央正回購持有的兩個主要無限期的分支：
主分支:master
發展分支:develop
在origin，主分支（master）應該被每一個Git用戶熟悉。平行於主分支，另一個分支存在稱為開發（develop）。
我們認為origin/master是一個主要的分支，在源代碼的頭總是反映一個生產准備狀態。
我們認為，origin/develop成為主要的分支，在源代碼的頭總是反映一個國家的最新發布的發展變化的下一個版本。有些人會把這個稱為“integration branch”。這個分支可以用來生成代碼的最新隔夜版本。
master分支上存放的應該是隨時可供在生產環境中部署的代碼（Production Ready state）。當開發活動告一段落，產生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本號標簽（tag）。
輔助分支：
下一個主要分支的主和發展，我們的發展模式使用各種支持分支機構，以幫助團隊成員之間的並行發展，便於跟蹤功能，准備生產版本，並協助快速解決生產問題。與主要分支不同的是，這些分支總是有一個有限的生命時間，因為它們最終會被移除。
我們可以使用的不同類型的分支：
用於開發新功能時所使用的feature分支：Feature branches
用於輔助版本發布的release分支 ：Release branches
用於修正生產代碼中的缺陷的hotfix分支：Hotfix branches
這些分支中的每一個都有一個特定的目的，並且被約束到嚴格的規則，分支可能是它們的分支，分支必須是它們的合並目標。我們將在一分鍾內步行穿過他們。
從技術角度看，這些分支“特殊”是不意味着的。分支類型被分類，我們如何使用它們。他們當然是普通的Git分支。
特征分支
分支可以來自：
develop
必須合並到：
develop
分支命名慣例：
feature分支的命名可以使用除master, develop, release-*, or hotfix-* 之外的任何名稱。
功能分支（有時也可以被叫做“topic分支”）是用來開發新功能，為即將到來或未來一個遙遠的未來。當開始開發一個功能時，該功能將被合並的目標發布可能是未知的，在這一點上。一個特征分支的本質是，它的存在，只要功能是在開發中，但最終會被合並回發展（肯定增加新功能，即將發布的）或丟棄（在一個令人失望的實驗的情況下）。一般而言，feature分支代碼可以保存在開發者自己的代碼庫中而不強制提交到主代碼庫里。
只有在開發商回購通常存在特征的分支，不在原點。
創建一個功能分支¶
當開始工作的新功能，分支從發展分支
$ git checkout -b myfeature develop
Switched to a new branch "myfeature"
結合完成的功能開發
完成的功能可能會被合並成的開發部門一定會添加到即將發行的：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
--no-ff標志導致合並總是創建一個新的提交對象，即使合並可以快速向前行。這就避免了一個功能分支的歷史存在的信息丟失和所有提交，一起添加的功能。比較：
在后一種情況下，它是不可能看到Git歷史的交付對象一起實現了一個功能，你需要手動讀取所有的日志信息。回復一個整體特征（即一組提交），在后一種情況下是一個真正的頭痛，而這是很容易做到的，如果使用--no-ff標志。
是的，它會創造一個更大的（空）的提交對象，但增益遠遠大於成本。
Release branches
分支可以來自:
develop
必須合並到:
develop and master
分支命名慣例:
release-*
發布分支機構支持新產品發布的准備。他們允許我最后點睛的交叉T的。此外，他們允許小錯誤修正和准備發布元數據（版本號、建立日期等）。通過在一個發布分支上做所有的工作，開發分支被清除以接收下一個大版本的功能。
關鍵時刻要從一個新的發行分公司的發展是在開發（幾乎）反映了所需的新版本的狀態。至少所有的功能，有針對性的發布必須建立在這一點上，在這一點上，以發展為目標。所有的功能，在未來的發布，可能不是他們必須等到發布分支是分支關閉。
它正是在一個發布分支的開始，即將發布的版本號被分配一個版本號而不是更早的。在那一刻起，develop部門反映了“next release”的變化，但目前還不清楚是否“next release”將最終成為0.3或1，直到 release branch開始。這一決定是在release branch的開始，是由項目的規則對版本號的碰撞。
創建release branch
release branch是從develop分支中創建的。比如說版本1.1.5是當前產能發布，我們有一個大的發布將要出來。develop狀態准備“next release”，我們認為這將成為1.2版（而不是6或2）。所以我們分支機構關閉，並給release branch一個名稱，反映了新的版本號：
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)
創建一個新的分支，切換到它，我們的版本號。在這里，bump-version.sh是一個虛構的shell腳本中的一些文件的工作副本的變化以反映新的版本。（這當然是一個手動的改變點，有些文件改變。）然后，被碰撞的版本號。
這個新分支可能存在一段時間，直到release可能被卷出。在此期間，錯誤修正可以應用於這一分支（而不是develop branch）。在此處添加新功能是嚴格禁止的。它們必須被合並成發展，因此，等待下一個大發行。
整理發布分支
當release branch的狀態已經准備好成為一個真正的release時，需要進行一些操作。首先，release branch是合並到master（因為每個提交都是一個新版本的定義，請記住）。下一步，commit onmaster必須標記為方便未來參考這個歷史版本。最后，發布分支的變更需要重新合並，以便將來發布還包含這些錯誤修正。
在Git中前兩步：
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.(Summary of changes)
$ git tag -a 1.2
現在發布的版本，並標記為未來的參考
Edit: You might as well want to use the -s or -u <key> flags to sign your tag cryptographically.
為了保持release branch的變化，我們需要合並回到develop，但在Git：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.(Summary of changes)
這一步可能會導致一個合並沖突（甚至可能，因為我們已經改變了版本號）。如果是這樣，修復它並提交。
現在我們真的做了，release branch可能被刪除，因為我們不需要它了：
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
Hotfix branches
分支可以來自:
Master
必須合並到:
develop and master
分支命名慣例:
hotfix-*
hotfix分支和release分支非常像，也要准備一個新的生產版本，盡管是意外。它們出現的必要性立即采取行動的不受歡迎的生活生產的版本。當一個生產版本的一個關鍵的錯誤必須立即解決，一個hotfix分支可能離開上主分支，標志着生產版本對應的tag。
其實質是團隊成員的工作（在develop branch）可以繼續，而另一個人正在准備一個快速的生產修補。
創建hotfix分支
hotfix分支與主支了。例如，說1.2版是目前的生產發行版，運行的生活和造成麻煩，由於嚴重的錯誤。但發展變化是不穩定的。我們可以再分支hotfix分支開始解決的問題：
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)
別忘了在分支關閉后凸點版本號！
然后，修復該錯誤並提交一個或多個單獨提交的修補。
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
完成一個hotfix分支
完成時，該功能需要合並到master，但也需要合並回develop，為了維護，修正是包含在下一版本，以及。這是完全類似於release branch如何完成。
首先，更新master和release 的 tag。
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.(Summary of changes)
$ git tag -a 1.2.1
編輯：你可能想使用-s or -u <key>flages標示你的標簽密碼。
下一步，包括bugfix在develop也一樣：
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.(Summary of changes)
該規則的一個例外是，當release branch目前存在，修補程序的變化需要合並到release branch，而不是develop。后合並修正到release branch將最終導致了被合並到develop，當release branch完成。（如果工作需要修正，不能立即開發這等待release branch來完成，你可以安全的把這個 bugfix 合並到 develop。）
最后，刪除臨時分支：
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).