前言
不懂git工作流，被辞退了！
之前在看到这句话的时候，我刚实习入职不久，瑟瑟发抖。好巧不巧，今天又看到了类似的文章讲git重要性的。
眼下，学校导师安排给我的课题组了一个新的工程项目，使用gitee维护，因此我打算写一篇文章总结一下git的工作流（git工作流就是指单人/多人团队如何使用git命令配合维护一个项目的一些约定的流程，在确保有效迭代的同时，保持高效的协作方式），相信可以帮助那些使用git停留在单人维护远程master分支的同学更进一步。
下面会讲解四种git工作流中的前两种，无论是在校课题组还是公司内部，都可以以此为基础找到合适的git团队工作模式。
Centralized Workflow 集中式工作流
介绍
三个开发人员共同维护一份远程仓库的代码，工作方式如下：
-
每次工作前从
remote拉取master分支到本地的master分支，然后处理冲突（使用IDE自带的GUI图形用户界面处理冲突会比较方便，如图中的goland内置的git工具）
-
接着开始编码，编码完成后
add修改的文件到缓冲区 -
commit缓冲区文件到自己local仓库，并且push本地仓库文件到remote仓库
评价
集中式工作流：这种工作方式简单粗暴，所有人只使用master分支维护项目，master永远是项目最新版本，编码比较快，立竿见影。但是所有开发者提交日志集中在一起呈单线延伸，难以定位问题，分工不明确，且容易发生冲突，处理冲突成本上升，但是单人开发很便利。
Feature Branch Workflow 功能分支工作流
介绍
功能分支工作流以集中式工作流为基础，在维护master分支的基础上，将项目的开发工作拆分为添加一个个的feature的形式，工作方式如下：
-
一旦需要开发新的功能，就在
remote的master分支的基础上创建一个feature xxx分支 -
本地创建对应的
feature xxx分支 -
每次开发前将
remote库的feature xxx分支拉取到本地，处理冲突 -
然后在本地
feature xxx分支上开发，然后push到remote的feature xxx分支 -
在项目主页上发起
pull request（如果是gitlab则是merge request，作用相同），本意是提出将feature xxx分支合并入master分支的请求
-
然后你的代码会被review，没通过就本地改，改完之后继续
push到remote（两头都在feature xxx分支），然后负责人继续review你这个PR或者MR，通过之后会将feature xxx分支区别于master的改动合并入master，删除remote的feature xxx分支，代表这个功能开发完毕
评价
功能分支工作流：这种工作方式带来了code review的功能，使得推送的代码更符合规范，减少bug产生。并且因为主要还是在master分支基础上根据功能需求创建feature分支，使得开发工作十分灵活，且各个功能之间隔离，但是对于大型项目而言需要为不同分支分配更加具体的角色，只有feature分支是不够的。
Gitflow Workflow
介绍
Gitflow工作流是我目前尚在熟悉的一种工作流，也是目前非常成熟的git工作流方案。区别于功能分支工作流，Gitflow工作流划分分支更有约束性。主要包括：
- 主分支master：用于跟踪项目正式发布的版本（tag标签号）
- 开发分支dev：用于跟踪代码研发的提交历史
- 功能研发分支feature：每次有新的功能需要研发，以
dev分支为基础，建立feature分支，开发完成后按上面feature branch工作流的方式提交PR/MR到remote的dev分支，完成之后删除对应feature分支 - 热修复分支hotfix：如上图所示，
master分支出现bug（线上报bug了），需要马上从master拉取一个hotfix分支处理修复bug，并且将代码合并到master和dev（这两个分支需要保持bug修复的一致性），修复后给master当前提交打一个tag（v0.2） - 发布分支release：在
dev基础上建立release分支，处理一些问题、修复一些bug之后，将代码合并入master与dev，并给master打上tag（v1.0）表示发布完成
评价
约束性更强，发布迭代流程更规范，严谨，开发人员分工更明确，十分推荐学习使用。
Forking Workflow
介绍
这种工作流是开源项目维护的工作流，暂作了解即可，通过将他人的项目fork到自己的remote仓库，就可以将其作为自己拥有的一份副本进行开发，比如想增加一个功能或者修复一个bug。这里A与C都fork了B的仓库，在各自开发完成新功能之后可以提交PR给B仓库，B仓库的开发者负责review代码，并接受PR。
评价
具体还未尝试过提交PR给开源项目，但是相信在掌握了上述三个git工作流之后，以后要使用到forking工作流的问题也应该引刃而解。
结束
学习了四种git工作流之后，并不是要完全照搬某一个模式的所有使用流程，而是应该结合实际的项目规模和人员规模进行合理安排。比如对于校内课题组较小的项目我认为feature branch工作流应该足以胜任，或者使用只有master、dev、feature的简化版Gitflow工作流。
我是白泽，一个有点逗比的程序员/学生党，咱们下期见。
欢迎大家关注公众号【程序员白泽】。
传送门
刚建了个微信小群，欢迎一起交流学习，备战秋招。
传送门
