git因为有分支的存在，才构成了多工作流的特色。在多人协作的项目开发中，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起。真实项目上会遇到很多问题，比如版本迭代、版本发布、bug修复、临时新增功能等等，为了更好的管理代码，需要制定一个工作流程。这个时候就出现了git flow、github flow、gitlab flow，当然也有很多公司将它们混和使用。
其中git flow出现的最早，github flow 在git flow的基础上，做了一些优化，适用于CI。而gitlab flow出现的时间较晚，所以综合前面两种工作流的优点，制成了一个新的flow。
git flow
git flow可以大致分为主要分支和协助分支。
主要分支
在git flow中代码仓库中会一直存在以下两个分支：
- master
- develop
其中origin/master分支上的最新代码永远是版本发布状态，origin/develop分支上对应的是最新开发进度。
当develop上的代码达到稳定程度，可以发布版本的时候，develop这些修改的方式会以一些特定的方式合并到master上去，然后标记对应的版本号。
协助分支
除了主要分支，git flow的开发模式还需要一系列的协助分支，来帮助更好的功能的并行开发，简化功能开发和问题修复。协助分支分为以下三类：
- Feature Branch
- Release Branch
- Hotfix Branch
Feature分支用来做分模块功能开发，命名看开发者喜好，模块完成之后，会合并到develop,然后删除自己。
Release分支是用来做版本发布的预发布分支，建议命名为release-xxx。例如在1.0.0版本，develop分支功能全开发完之后，提交给测试之后，会从develop分支拉出一个Release-1.0.0分支，测试给推送给过来的小问题，在release-1.0.0分支上修改，测试完毕准备发布的时候，会把代码合并到master和develop分支上，master分支合并完后会打对应的tag，比如v-1.0.0。为了在测试的时候不影响下一个版本的功能并行开发，删除对应release分支。
Hotfix分支主要是为了解决正式上线版本有一些紧急的bug。比如线上版本上出现了很严重的bug，需要理解修复。这个时候我们需要从master拉出一个对应的分支，比如取名hotfix-xxx,解决完bug，提交测试，没问题然后合并到对应到develop和master,并给master打对应的tag。然后删除hotfix分支。
看看官网的流程图：
git flow
官网推荐我们git merge的时候加上 no-ff参数，意思就是不用fast-forword的合并方式，而是有策略的合并，这样会让我们多一个合并提交。这样保证了一个很清晰的提交历史，可以看到被合并分支的存在。
区别
github flow
github flow就简单太多了，他只有一个长期分支-master分支。这个分支上的代码永远是发布状态。一般这个分支的会设置protected分支保护，只有有权限的人才能推送代码到master分支。
当需要开发新功能时，需要从master分支创建一个功能分支。本地分支开发完代码之后需要定时向远程分支推送代码。当你需要帮助或者你想合并分支的时候，可以发起一个pull request(对应的gitlab merge request)，当review或者讨论通过后，代码会合并到目标分支，一旦合并到master分支，就应该立即发布。。
通常这个会配合ci同时使用，当代码一有变动，就自动发布。这里pull request就跟拉个讨论组差不多，提供了评论功能支持。可以选择相关的人参与，而且参与的人还可以向你的分支提交代码。还有一个issue tracking（问题追踪）功能，也就是提交信息中包含 fix #1等信息就可以自动关闭对应的编号的issue,一般未解决的issue为open,解决了就是closed。
gitlab flow
gitlab flow的出现当然是为了补足git flow、github flow的不足。
git flow暴露了很多问题：
- 默认工作分支是develop,需要从master切换。
- hotfix和release分支他们分别从master分支、develop分支创建，使用完毕后，必须合并回master和develop，可能在实际开发中会忘记。
- hotfix和release分支在快速迭代的项目里，基本用不到，开发完就直接合并到master了，出现问题develop修复直接发布下一个版本了。
github flow简化了git flow的流程，一定程度上解决了上面的问题，还提供了ui操作工具。但是github flow也会存在一些问题，比如：
- 版本发布会被推迟（比如并行开发移动端，需要发布）
- 需要不同环境的部署（例如:测试环境（即之前公司用的uat），预发环境（之前公司用的stage），正式环境（之前用的console））;
- 不同的版本发布和bug修复。（所以一个分支根本不够。）
针对问题1. gitlab flow 就提供了prodution 分支，比如上面说的console。专门同来发布版本。
针对问题2. gitlab flow提供了 多个prodution分支，比如uat,stage,console。uat没问题上升到stage,stage没问题上升到console.
针对问题3. gitlab flow 建议的做法是每一个稳定的版本，都要从master分支上拉出一个分支，发现问题就从对应拉出的分支上创建修复分支，完成之后，先合并到master,才能合并release。
总之，git还提供了很多自定义工作流的hook, .git/hooks目录下。分为客户端hook和服务器端hook。这个我了解一下，感觉git还是很强大的。。
近况
最近换了一个工作，工作虽然是个创业公司，但是不得不说我很满意。大佬们很耐心，会很耐心的教，我们不懂也会提供思路教我们，让我们自己去学，给我们时间学。想起以前十来个模块的业务代码，内心是崩溃的。。如果自己不挤出时间学，是很难有进步的。从去年开始上班到现在（虽然现在还是很菜），但是总体感觉进步了不少(对比以前自己是个天天泡网吧的网瘾少年，除了打游戏啥也不会。)，不管是以前公司，还是现在的公司，心里都是非常感谢的。。
不多BB了 ，下面拿出自己尘封已久的博客：CBC
前端登录的时候有点小bug,懂nginx大佬可以帮我看看，登录的时候看下浏览器控制台。当然后台系统就不提供出来了。。
偶尔看看电影可以去这：电影
账号:cbc 密码:674181203
当然你可以注册账号，人脸识别服务器上用不了（没有域名，浏览器不给打开摄像头，本地是可以的），注册的时候可以跳过。
网友评论