如何做代码管理（二）--Git提交流程
Git提交流程
上面说了这么多基础的Git知识，接下来就一起来看看日常开发当中的实践。正如上面所说Git的分支开销很小，所以可以很方便的切换分支，也是因为如此，有几种比较流行的Git分支模型。
Git分支模型
GitFlow
GitFlow最早是由Vincent Driessen发明的，目前仍然广泛采用的一种工作流程。
先看这张图片的最上面，master主分支和develop开发分支是加粗的，在整个的开发周期内，这两个分支一直存在。主分支的任何一次提交都是一个稳定的版本，开发分支就是目前最新的开发版。
在这两个分支之外，有三个功能分支：
- feature branches：功能分支，开发某个功能的分支
- release branches：发布分支，往外释出版本的分支
- hotfixs：修复分支，修复bug的分支
这三个分支都是临时性的，做完之后都会合并进入到develop分支当中。GitFlow看起来相对比较复杂，需要维护两个分支。
GitHub Flow
看到这个名字就知道，这是Github推行的一个工作流。因为现在持续集成已经成为主流，所以通过GitFlow的方式来控制发版，还是很复杂。Github Flow相对于上面有了很多简化，详细的可以看Github官网的介绍。
在使用过程中，每次都从master检出一个新的分支，在这个分支执行feature开发/hotfix的处理，在编写完代码之后，只需要向主分支发起PR（pull request）进入code review，确认代码没有问题之后，会将这一次PR的代码合并去master中即可。
可是Github Flow也有一个缺点，假如说发布软件有一定的窗口期，这样就会导致线上运行的代码和实际的master代码产生不一致。
Trunk-Based Development
随着敏捷开发和持续集成思想逐渐变成主流，演变出来了一种Trunk-Based Development的开发方式。在这个方式下，所有的提交都在master分支，测试和开发都相对的简单起来。但这会引出三个问题（出自分支模型与主干开发）
如何避免发布的时候引入未完成的 Feature
如何进行线上 Bug Fix
如何重构
上面的引用连接中有关于这三种情况的解答，感兴趣的话，可以去看看。
提交流程
说完了分支模型，下来简单的说一下提交的流程
- 在Jira，看板等工具中领取Task
- 在dev分支切一个新的分支（Feature分支或者Fix分支）
- 开发完毕之后，推送本地新建的分支到远程代码仓库
- 新建一个PR请求，并添加代码评审员（code reviewer）
- 等待代码评审（code review approve）结束后，合并到dev分支
- 自动部署，自动打包程序出包，QA team测试验证结果
- 测试通过
可能在各家公司的要求都不是特别一样，但总体来说流程会相似。或者在不同的项目（例如公司项目和个人项目）可能会有少许的差异，需要灵活的变通和调整。
REF ：
