Git 的晦涩难懂
Git 是一个非常优秀的代码管理系统，在团队协作中发挥着重要的作用。
但是往住有的团队在不了解的情况下使用 git 或者，初学者使用 git 的时候并不觉得这是一个优秀的工具，相反，觉得晦涩难懂，而且经常出现代码冲突。这是一个仅仅停留在只会用 git add，git commit，git push 这三个命令典型，不懂 git 工作流的典型。
Git 工作流
在解释 Git 工作流之前，我们知道团队开是有一套具体的流程的，这个流程是约定的，大家认同的，如果有谁不按这个流程来做，那么他工作一定很辛苦。
同样，Git 也是这样的。
Git 工作流也叫：Git flow，这是一个 git 的插件，它预定义了代码提交的流程，它做的仅仅是把常用的几个命令组合起来，然后套进一个约定的模式里，是的，它仅仅是一种思想。
换个说法：你不需要安装什么其实就可以用 Git flow
Git 工作流的思想
其实在项目不是很大的情况下，只需要要约定下面这个 Git flow 就够用了：
master 只能用来包括正式代码。你不能直接在 master 分支上开发，而是在其他指定的，独立的特性分支中开发。不直接提交改动到 master 分支上也是其它工作流的一个共同的规则。
develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是基础。另外，当开发完的功能合并到 develop 分支后，就应该进行测试，测试完成通过后，等待被整合到 master 分支中。
feature/xxx 分支仅仅存在于开发过程，开发结束合并到 develop 分支之后将删除。
以上是一个非常小而简单的工作流，仅仅涉及到简单的开发和测试，适合小团队小项目使用。
如果是一个非常庞大的项目或者成百上千人的开发团队，那么，估计还需要 pre-release，hotfixer，release 等这几个分支来实现代码的稳定发布。
举个例子
开发一个新功能 hello_world，我们首先需要做的是在 develop 的基础检出一个新的分支：feature/hello_world
git checkout -b feature/hello_world之后，所有 hello_world 的功能开发代码都是提交到 feature/hello_world 这个分支的。
等到所有功能开发完毕之后，我们把这个分支合并到 develop 分支，然后删除它：
# 先切换到 develop 分支git checkout develop# 更新 develop 的代码，避免合并产生推送冲突git pull# 合并分支git merge feature/hello_world# 删除分支git branch -d feature/hello_world到这个时候，代码都是在 develop 了，一般情况需要到测试环境进行进一步的测试（合并到 develop 之前就应该完成基本的全部测试及 bug 修复），这里基本是测试一下稳定性及兼容性，测试通过之后，再合并到 master 分支进行发布：
# 切换到 master 分支git checkout master# 合并 develop 分支git merge develop最后
Git flow 是一种工作流的思想，让团队协作更容易，上面举的仅仅是一个简单的例子，当真正理解工作流之后，完全可以自己再进行定义，毕竟每个团队都不一样。