git-flow

版本控制对于程序开发的重要性不言而喻。现在主流应该就是git了。

做开发的同学们应该都知道需要使用版本控制，但是在实际的使用过程中总是会遇到一些问题。比如想要紧急修复线上bug,但是还有未完成的功能，无法发布等。大多数问题其实都是没有统一的工作流程或者说是工作流程不合理造成的。

当你有这些烦恼时，向你隆重推荐git-flow，你可以认为它是一个工具，我个人认为它更是一种思想，或者具体说是一套合理的方法或者工作流程。

具体的操作方法在这里就不再赘述了，可以自己安装命令行工具，也可以使用软件，比如sourceTree或者IDE的插件等。本文主要分析它的思想或者原理。

1.git-flow的初始化。

和git仓库初始化一样，在启用git-flow时需要先进行初始化，这时可以指定一些分支的名称等，建议不做任何修改。

2.分支

2.1 长期分支

在初始化项目后，自动创建两个分支，一个是develop，一个是master.

master 只能用来包括产品代码。你不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。

develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。

简单来说，master是最稳定方式，develop是相对稳定但是最新的分支。需要注意的是，这两个分支都是整个开发周期长期存在的，并且不能直接在这两个分支上工作，也就是说不能向这两个分支上提交代码，它们的代码都是从其它分支合并过来的。

2.2 功能分支

字面意思理解就是用于开发一个新功能的分支。在新需求来的时候，通常是从develop在检出一个feature/功能分支名 的分支来开始新的需求。有的同学可能会说为什么不在develop上直接工作呢，使用版本控制很大一部分的原因就是协同工作。 同时可能有多个feature分支在向前进，当一个完成时，其它的feature分支还没有完成，如果产品需要发布，就尴尬了。所以我们在每个需求来的时候都需要开一个feature分支，因为develop分支上有最新的代码，所以都是从这个分支上检出的。

当我们完成了一个功能，经过测试，没有什么大问题了，就可以切换到其它分支进行工作了。此时注意不要直接完成这个功能，因为我们不确定下次版本发布是否需要发布这个功能。但是我们知道完成这个功能提意思就是说把代码直接merge到develop分支上并且删除这个分支。

2.3 发布分支

当我们需要发布版本时会使用到这个分支，此时我们首先在确定要发布的内容，选择那些需要发布的功能分支，然后完成这些分支，代码自动合并到了develop，bugfix分支必须是要带上的，不需要再考虑了。然后我们在develop上就是我们需要发布的代码了，此时检出一个release分支。打包测试，修复bug。

当我们确定可以发布时，也就是这个release分支完成了。此时会把代码自动合并到develop，并且打一个tag，然后再合并到master，最后再删除这个分支。

2.4 bugfix分支

有的地方也叫hotfix分支，是用来处理线上bug的。当我们在线上有紧急的bug需要修复时，应该从master上checkout一个bugfix分支，因为master才是最稳定的，我们这次发布的目的是快速解决紧急bug而不是发布新功能，所以应该从master分支检出。

当我们完成这个分支时，代码会自动合并到develop和master，打上一个tag,最后还是删除这个分支。

3 流程

上边我们已经介绍过每个分支的功能，使用场景和最后的效果。下边我们来看图

当我们理解git-flow的思想之后，明白了它的工作流程，其实git-flow就是提供一些git命令的组合罢了，核心是它的思想。至于最后使用的具体工具是什么，都会非常轻松。