Git提交流程

上面说了这么多基础的Git知识，接下来就一起来看看日常开发当中的实践。正如上面所说Git的分支开销很小，所以可以很方便的切换分支，也是因为如此，有几种比较流行的Git分支模型。

Git分支模型

GitFlow最早是由Vincent Driessen发明的，目前仍然广泛采用的一种工作流程。

先看这张图片的最上面，master主分支和develop开发分支是加粗的，在整个的开发周期内，这两个分支一直存在。主分支的任何一次提交都是一个稳定的版本，开发分支就是目前最新的开发版。

在这两个分支之外，有三个功能分支：

feature branches：功能分支，开发某个功能的分支
release branches：发布分支，往外释出版本的分支
hotfixs：修复分支，修复bug的分支
这三个分支都是临时性的，做完之后都会合并进入到develop分支当中。GitFlow看起来相对比较复杂，需要维护两个分支。

看到这个名字就知道，这是Github推行的一个工作流。因为现在持续集成已经成为主流，所以通过GitFlow的方式来控制发版，还是很复杂。Github Flow相对于上面有了很多简化，详细的可以看Github官网的介绍。

在使用过程中，每次都从master检出一个新的分支，在这个分支执行feature开发/hotfix的处理，在编写完代码之后，只需要向主分支发起PR（pull request）进入code review，确认代码没有问题之后，会将这一次PR的代码合并去master中即可。

可是Github Flow也有一个缺点，假如说发布软件有一定的窗口期，这样就会导致线上运行的代码和实际的master代码产生不一致。

随着敏捷开发和持续集成思想逐渐变成主流，演变出来了一种Trunk-Based Development的开发方式。在这个方式下，所有的提交都在master分支，测试和开发都相对的简单起来。但这会引出三个问题（出自分支模型与主干开发）

如何避免发布的时候引入未完成的 Feature
如何进行线上 Bug Fix
如何重构
上面的引用连接中有关于这三种情况的解答，感兴趣的话，可以去看看。

说完了分支模型，下来简单的说一下提交的流程

可能在各家公司的要求都不是特别一样，但总体来说流程会相似。或者在不同的项目（例如公司项目和个人项目）可能会有少许的差异，需要灵活的变通和调整。

REF ：