Gitflow（git工作流）

我第一次接触这个概念，是出于一个偶然的机会，用的Git客户端SourceTree ,在右上角有个按钮“git工作流”，出于好奇点开看了下，弹出对话框如下图所示，在网上搜了下，gitflow的相关资料，感觉非常棒。

我印象中的git是这样用的

1. 每开发一个版本，就从master分支上fork出一个分支来。然后，在该分支上开发当前版本的功能。开发完毕后，将该分支合并会master分支。
2. 然后，进行下一个版本迭代的时候，再从master分支上fork出一个新的分支来，开发完毕后，再合并回master分支。这样周而复始，继续下去。
3. 这样并没错，但是会带来个问题，每迭代一个版本，就要从master上fork出一个分支，开发完毕后，在合并到master分支上，很是繁琐。每个版本开发过程中，都需要进行这样一个重复性的繁琐工作。

直到我看到了gitflow,才顿感轻松

gitflow的工作方式

1. 一个master分支：我们从不直接在上面工作，主要用来开发完毕后，合并至master分支；
2. 一个develop分支：我们在该分支上进行功能开发，所有的开发工作以该分支为主分支，可以在该分支上进行各种操作；
3. release分支：该分支fork自 develop分支。当develop上的开发工作完毕（或者是到了预定的发布日期时），从develop分支上fork出来，用于进行发布—— 这个分支只应该做Bug修复、文档生成。 一旦对外发布的工作都完成了，发布分支合并到master分支并分配一个版本号打好Tag。 另外，这些在该分支做的修改要合并回develop分支，因为develop要继续下去，而在release上做的修改也需要添加到develop上。
4. Hotfix（bug分支）：项目发布，接到用户反馈的bug后，需要及时修复。这个时候可以从master fork出一个bug分支，fix完bug后，再将该分支合并会master分支。

gitflow的工作方式，相比我印象中的git工作方式，确实强大很多：

1. 只在一个develop分支上干活，不需要在每个版本迭代时候都fork出一个分支来，避免了大量的重复劳动；
2. develop分支上的工作完成，到预定发布日期的时候，fork出release分支来（可以切换到生产环境，这样，就可以避免在develop上频繁的改动生产、测试环境的接口）
3. 从开发到发布从不与master进行直接交互（不在master上干活），保证了master分支的稳定性。

参考资料：

1. Git工作流指南：Gitflow工作流
2. Git工作流指南
3. git学习资料