gitlab 的使用策略和简单介绍
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).
