标签：style http color io 使用 ar 数据 问题 cti
这篇文章联系了自个的项目经历及网上材料，再加上个人的一些体会。出于对git办理工具的酷爱，特编写此文。
git办理模型
http://www.nuoyapingtai.net 诺亚平台 www.nuoyapingtai.net
常见的解法是求解节点到根的途径，对途径做比对。参见：http://www.lyhfyl.com http://www.lyhfyl.com
分布式但集中化，这是对git办理模型最佳的论述。模型图如下图所示：
上图中origin是一个"中间库"，当然这个中间库只是被认为是这样(由于Git是分布式的，从技能层面上来说是没有中间库的)。
每个开发者pull和push到origin，但除了中间化的push-pull关系外，每个开发者还能够从其他开发者那pull changes。比方说，关于一个比较大的新特性，在把代码提交到origin之前，很可能会组织2个或多个开发者。上图中有几个小团队：Alice和Bob，Alice和David，Clair和David。团队成员先把代码pull到队长那里，再由队长pull到origin库。
首要分支设计
中间库房有两个分支：master和develop。
origin上的master分支，Git用户应当很熟悉，跟master并行的有一个develop分支
咱们把origin/master作为首要分支，源码的HEAD老是表明production-ready(可随时布置)状况。而origin/develop上的代码是为下一次的代码发布预备的。每日构建也是基于此分支。
当develop分支达到了一个安稳状况并预备发布时，一切的改动都要兼并到master分支，并标上版别号。这样每次与master兼并都会会有新的布置发布。如下是有关指令：
$git checkout –b develop master
在develop分支上进行开发作业。
$git checkout master
$git merge –no-ff develop
支撑分支设计
咱们的开发模型使用了一些支撑分支放在master和develop分支的旁边，便利开发小组之间的并行开发。不像首要分支，这些分支是有时间约束的，由于他们终究都会被移除。
咱们会使用到的不一样的分支有：Feature branches、Release branches、Hotfix branches。
每个分支都有各自的作用，并且有严厉的规则，如：只能从哪个分支上去新开分支，只能兼并到那个分支。
Feature branches
规则如下：
承继分支: develop
兼并分支：develop
命名标准：除了master,develop,release-,hotfix-
Feature branches是用来开发新特性的(短期，远期都能够)。当开端开发新特性时，很可能不晓得这个特性会出如今哪个方针版别。一旦开发完结就能够兼并到develop，当然假设开发失败，就能够扔掉。
创立及完结一个 Feature branch
依据Feature branches的规则，创立指令如下：
$ git checkout -b myfeature develop
新特性完结时，能够兼并到develop
$ git checkout develop
$ git merge --no-ff myfeature
$ git branch -d myfeature
$ git push origin develop
—no-ff (注：no fast foward)标签，使得每一次的兼并都创立一个新的commit记载。即使这个commit只是fast-foward，这样能够防止丢掉信息
Release branch
规则如下：
承继分支: develop
兼并分支：develop 和 master
命名标准：release-*
Release branch 是为新的production release预备的，能够有一些小的bug，并为发布预备一些元数据(版别号，构建日期等等)。把一切的这些作业都放到 Release branch，develop branch就能更明晰地晓得下一个版别要开发哪些特性。
从develop分支兼并到release分支的关键因素是:develop分支达到了release分支所要求的状况。最少一切对于该release的特性要被兼并。至于那些将来会有的特性能够先放一放。然后即是为接下来即将要发布的版别分配一个版别号。
创立一个Release branch
Release branch是经过develop分支而创立。举个比方，假设1.1.5是当时的production release，然后会有一个比较大的版别发布。develop的状况现已能够发布版别了，经过商讨后，决议发布为1.2版别，所以咱们创立一个release分支，并给这个分支一个新的版别号
$ git checkout -b release-1.2 develop
这个新分支可能会存在必定的时间，直到能够被兼并到production branch。这段时间内，bug修补能够在这个分支上进行(而不是develop分支)。增加新特性(特别比较大的)是不允许的。终究仍是要被兼并到develop，然后持续在develop分支上开发，直到下一个版别。
完结一个release branch
当release branch现已预备就绪，需求做几件事。首要，release分支被兼并到master分支上(每一个提交到master上的commit都是一个新版别，牢记)。然后master上的commit都要增加tag，便利将来检查和回滚。终究release上所做的修改有必要兼并到develop分支上，确保bug已被修补。
前两个过程：
$ git checkout master
$ git merge --no-ff release-1.2
$ git tag -a 1.2
为了把release上的改动保存到develop，咱们需求兼并到develop
$ git checkout develop
$ git merge --no-ff release-1.2
这个过程可能会致使抵触，假设这样的话，处理抵触，然后再提交。
如今一切都完结了，能够把release branch干掉了。
$ git branch -d release-1.2
Hotfix branch
规则如下：
承继分支: master
兼并分支：develop 和 master
命名标准：hotfix-*
Hotfix branch和Release branch有几分类似，都是为了新的production release而预备的。比方运转过程中发现了bug，就有必要疾速处理，这时就能够创立一个Hotfix branch，处理完后兼并到master分支上。优点是开发人员能够持续作业，有专人来担任搞定这个bug。
创立Hotfix branch
Hotfix是从master分支上创立的。假设当时运转版别是1.2，然后发现有bug，可是develop还在开发中，不太安稳，这时就能够新开一个Hotfix branch，然后开端处理问题。
$ git checkout -b hotfix-1.2.1 master
处理问题，一次或几回commit
$ git commit -m "Fixed severe production problem"
完结Hotfix branch
当结束时，bugfix要被兼并到master，一起也要兼并到develop，确保下个版别发布时该bug已被修正。这跟release branch完结时一样。
首要更新master和tag release
$ git checkout master
$ git merge --no-ff hotfix-1.2.1
$ git tag -a 1.2.1
接下来与develop兼并
$ git checkout develop
$ git merge --no-ff hotfix-1.2.1
有一个破例，即是当存在一个release branch存在时，bugfix要被兼并到release而不是develop，由于release终究会被兼并到develop。
终究移除branch
$ git branch -d hotfix-1.2.1
总结
这个办理模型应当算是达到行业标准的一个模型了。在实践的开发过程中，假设不必太过于考虑项目本钱及项目成员的才能水平常，这样的模型应当是首选。
标签：style http color io 使用 ar 数据 问题 cti
原文地址：http://www.cnblogs.com/haomad/p/3960259.html
