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 是一种工作流的思想，让团队协作更容易，上面举的仅仅是一个简单的例子，当真正理解工作流之后，完全可以自己再进行定义，毕竟每个团队都不一样。