GitHubFlow&GitFlow基于Git的两种协作开发模式
介绍基于Git两种协作开发模式,GitHubFlow&GitFlow
对于Github一些好用的特殊操作技巧
一GitHubFlow
GitHubFlow——?以部署为中心的开发模式,通过简单的功能和规则，持续且高速?安全地进行部署。在实际开发中往往一天之内会实施几十次部署，而支撑这一切的，就是足够简单的开发流程以及完全的自动化。
GitHubFlow?特点：
令master分支时常保持可以部署的状态
进行新的作业时要从master分支创建新的分支，新分支名称要具有描述性
在2新建的本地仓库分支中进行提交
在Github端仓库创建同名分支，定期push
需要帮助、反馈，或者branch已经准备merging时，创建PullRequest，以PullRequest进行交流
让其他开发者进行审查，确认作业完成后与master分支进行合并（合并的代码一定要测试
与master分支合并后，立刻部署
使用GithubFlow的前提条件：
团队规模最好控制在15-20人之内
部署作业完全自动化。必须自动化，一天之类需要多次部署
使用部署工具（Capistrano，Mina，Fabric,Webistrano,Strano等），让部署时所需的一系列流程自动化。
通过Web界面进行部署，Capistrano等部署工具需要命令执行操作，开发者以外的人很难实施部署
Capistrano?//Ruby开发的代表性部署工具
Webistrano?//可以通过Web执行Capistrano的工具
导入开发时注意事项：随着团队人数的增多及成熟度的提高，开发速度会越来越快。往往一个部署尚未完成，另一名开发者就已经处理完下一个pullrequest，开始实施下一个部署。在这种情况下，一旦正式环境出现问题，很难分辨哪个部署造成了影响。为了应对该情况，建议在部署实施过程中通过工具加锁。
GitHook自动部署
重视测试
让测试自动化
编写测试代码，通过全部测试
维护测试代码
二GitFlow
荷兰程序员VincentDriessen曾发表了一篇博客，让一个分支策略广为人知。具体流程见下图（引用该博客的一幅图片）
这一流程最大的亮点是考虑了紧急Bug的应对措施，整个流程显得过于复杂，所以在实施该方案前，需要对整个开发流程进行系统的学习。也需要借助Gitflow等工具的辅助。
下面根据上图，按不同分支进行说明：
master分支和develop分支
在GitFlow中，这两个分支至关重要，它们会贯彻整个流程始终，绝对不会被删除。
master分支
master分支时常保持着软件可以正常运行的状态。由于要维护这一状态，所以不允许开发者直接对master分支的代码进行修改和提交。
其他分支的开发工作进展到可以发布的程度后，将会与master分支进行合并，并且这一合并只在发布成品时进行。发布时将会附加版本编号的Git标签。
develop分支
develop分支是开发过程中代码中心分支。与master分支一样，这个分支也不允许开发者直接进行修改和提交。
程序员要以develop分支为起点新建feature分支，在feature分支中进行新功能的开发或者代码的修正。也就是说develop分支维系着开发过程中的最新代码，以便程序员创建feature分支进行自己的工作。
在feature中工作
feature分支以develop分支为起点，是开发者直接更改代码发送提交的分支。开发流程：
从develop分支创建feature分支
从feature分支中实现目标功能
通过Github向develop发送pullrequest
接受其他开发者审核后，将PullRequest合并至develop分支
具体指令：
$gitcheckoutdevelop
$gitpull
$gitflowfeaturestartadd-user//addbranchfeature/add-user
$gitbranch
//feature/adduserstartcommitcommit....
$gitpushorginfeature/add-user
//到github上去代码审查，切到develop分支，进行pullrequest
$gitcheckoutdevelop
$gitpull//当feature/add-user合并到develop后，本地develop需要更新到最新状态
注意，默认状态是pullrequest到master。这时需要手动切换到develop分支，再进行pullRequest操作。如果采用该开发策略，那么可以在setting中Option中，修改DefaultBranch为develop，这样就省去了手动修改的麻烦。
与develop分支合并后，已经完成工作的feature分支可以在适当的时机删除
更新本地的develop分支
我们发送的pullrequest在github端与develop合并后，为了让其反应到本地的develop分支中，我们需要进行以下操作：
切换到develop分支
执行gitpull(fetch&merge)
每当需要从develop分支创建feature等分支时，记得一定要先执行上述操作，保证develop分支处于最新状态。
release分支
创建release分支?，在这个分支，我们只处理与发布前准备相关的提交，比如版本编号变更的元数据的添加工作。如果软件部署到预演环境后测试出bug，相关修正也要提交到这个分支。
注意：该分支绝对不能包含需求变更或者功能变更等重大修正。这一阶段的提交数应该限制到最低。
$gitcheckoutdevelop
$gitpull
$gitflowreleasestart''1.0.0''
当所有修正处理完后，我们结束这分支
$gitflowreleasefinish''1.0.0''
//期间会需要填写提交信息、这个版本的提交信息、合并的提交信息。无特殊情况，一般默认。
全部结束后，会显示如下
$gitflowreleasefinish''1.0.0''
Switchedtobranch''master''
Yourbranchisup-to-datewith''origin/master''.
Mergemadebythe''recursive''strategy.
README.md|2++
1filechanged,2insertions(+)
Switchedtobranch''develop''
Yourbranchisup-to-datewith''origin/develop''.
Alreadyup-to-date!
Mergemadebythe''recursive''strategy.
Deletedbranchrelease/1.0.0(wasd3f54a0).
Summaryofactions:
-Releasebranch''release/1.0.0''hasbeenmergedinto''master''
-Thereleasewastagged''1.0.0''
-Releasetag''1.0.0''hasbeenback-mergedinto''develop''
-Releasebranch''release/1.0.0''hasbeenwww.hunanwang.netlocallydeleted
-Youarenowonbranch''develop''
查看版本tag
通过前面一系列的操作，我们创建了与发布版本号相同的Git标签
$gittag
1.0.0
更新到远程仓库
对此，我们对多个分支进行了修改，所以需要利用push操作将修改更新到Github端的远程仓库。先从develop开始
$gitpushorigindevelop
然后是master
$gitcheckoutmaster
$gitpushoriginmaster
再push标签信息
$gitpush--tags
这样版本号1.0.0的标签信息就已经push完成
在hotfix分支下进行工作
下述情况需要创建hotfix分支
release版本中发现了bug或者漏洞
develop分支正在开发新功能，无法面向用户进行发布
漏洞需要及早处理，无法等到下一次版本发布
假设修复BUG后的版本至1.0.1
$gitfetchorigin
现在以1.0.0的标签信息为起点，创建名为1.0.1的hotfix分支。
$gitflowhotfixstart''1.0.1''''1.0.0''
修复工作结束后，将hotfix分支push到github端的远程仓库，并向master分支发起PullRequest
$gitpushoriginhotfix/1.0.1
创建标签和进行发布
在Github项目主页，点击release，为本次hotfix创建1.0.1标签。点击Draftanewrelease按钮，输入相关标签信息，在Target中指定master分支（master分支已经合并了hotfix1.0.1的修改）。然后填写相关信息，点击Publishrelease进行发布
1.0.1发布后，之前发布的成品也就完成了生命周期
$gitfetchorigin
从hotfix分支合并到develop分支
登录到Github，从hotfix1.0.1分支向develop分支发送PullRequest即可。审查后便会被合并到develop分支
GitFlow的小结
建议把开发流程图放大贴在墙上，这样能够有效帮助团队成员理解流程内容
版本号的分配规则x.y.z
x:在重大功能变更，或者版本不向下兼容+1，此时yz归零y:在添加新功能或者删除已有功能+1此时z归零z:只在进行内部修改后+1.
|
|
