写在前面
在我第一次接触编程的时候，学的是Pascal，在那个叫做Turbo的蓝屏编辑器里写下一些简单的流程控制去解一些简单的算法题。那时候，天还很蓝，我的代码还保存在自己电脑的文件夹里。
上了大学以后知道了github这个东西（aka: gayhub），而后又去了解了git的概念，也从字面上明白了对于一个项目的开发人员而言，版本控制是一件很重要的事情。
当有了项目经验以后，不再是自己一个人coding了，由于责任的划分、产品的迭代等方面都出现过一些小范围内毁灭性的“失误”，所以终于深刻意识到了版本控制是一件重要的事情。
目前最流行的版本控制工具有两种：svn和git。
因为一些开源社区和自身特点的原因，git似乎更受广大开发者的青睐。
（本文所介绍的工作流是借鉴livoras大神的相关issue）
什么是git？
关于git的概念，大概分为以下三点：
打开浏览器
在地址栏输入“baidu.com”
搜索：“什么是
git”
一些概念的正确打开方式
仓库
就像图中所示，仓库有两大类：源仓库（最中间的）和开发者仓库（四周的）。
源仓库就是项目发起人所建立的仓库，其他开发者只能基于这个仓库对项目进行开发。
开发者仓库则是众多开发者们从项目发起这那里fork来的，可以在自己的主页看到这个“转发”来的仓库，相应的，开发者的commit和push操作都是基于这个克隆体来进行的。
分支
分支在git中是一个很重要的概念（当然了，svn中也有）。
在git中，分支主要分为两种：永久性分支和临时性分支。
永久性分支
一般情况下就是指master和develop这两个分支，前者用于保存产品每个版本的代码，通常由develop分支合并而来；后者则是开发者的主要战场。
临时性分支
根据不同的用途，可将临时性分支分为以下三种：
功能分支
预发布分支
bug修复分支
我喜欢把临时性分支成为备胎分支，因为她们的设定非常符合用完即走的产品理念（备胎们哭晕在仓库）。
可能你会有点不理解为什么这些分支的命运如此悲凉，那我来举个栗子
有一天，产品要求小明给主页增加一个点赞的功能，说时迟那时快，小明撸起袖子就是干
$ git checkout -b feature-thumbsUp
//新建一个功能分支
$ vi thumbsUp.js
//进行开发
$ git add thumbsUp.js
$ git commit -m 'add feature-thumbsUp'
//将当前分支的的修改保存到本地
$ git checkout develop
$ git merge --no-ff feature-thumbsUp
$ git branch -d feature-thumbsUp
//切换到develop分支并且合并刚才功能分支的修改
//并且删除那个功能分支（虐不虐！你就说虐不虐！用完即走啊！）
$ git push origin develop
//push到自己的远程仓库看到了吧，这就是临时性分支的悲惨命运。不过话说回来，为了整个项目的推进而牺牲不失为一件光荣的事情。
Workflow
ok，接下来就到本文的Highlight了，一种可靠的工作流——使用git和github进行协同开发（livoras大神的 那篇文章也叫这个名字，大家可以去看看）
step 1
找到源仓库并fork之，clone这个“转发”来的副本（开发者仓库）。
step 2
在本地就可以进行开发啦，进入develop分支（你的主战场），并根据需求创建临时分支进行开发，最终合并到develop分支。
自己搞好以后就可以push了，但这并不是上传到源仓库，而是你的开发者仓库。
step 3
此时对于 自己刚才上传的代码，你肯定满满的自信，大概是：“卧槽我怎么这么帅真是写得一手好代码”，肯定是希望项目的发起者（管理员）将你的贡献“收录”了，这时，就需要你去提交一个pull request（江湖人称PR）。
提交之后，剩下的工作就交给管理员了。
step 4
管理员看到了你的PR，可以在github上面直接review你提交的更改，下一步，他会在本地仓库输入以下命令：
$ git checkout develop
$ git checkout -b kyrieliu-develop
$ git pull https://github.com/kkkyrie/project.git develop
//将你的代码pull到本地的测试分支中进行测试如果管理员确定没问题，一般情况下就会接受你的PR了。
当然，可以通过两种方法接受一个PR：
直接在github上接受
命令行：
$ git checkout develop
$ git merge --no-ff kyrieliu-develop
$ git branch -d kyrieliu-develop
$ git push origin develop通过上述的步骤，由你新加的thumbsUp.js就从你本地经历了万水千山最终到达了源仓库。
有冲突了？莫慌！
在实际操作中，经常会出现有冲突的情况，作为一个同样遇到过冲突并且最终解决了的人，我由衷的告诉你：不要慌，出现冲突也是一件很平常的事情，实在解决不了那就无脑回滚吧！（噗哈哈哈）
如果其他开发者在你开发的过程中有上传新的代码，在你pull之前一定要先commit你本地的修改，不然可能等你pull下来以后会发现：卧槽我刚写的代码呢？
另外，个人觉得git的提示还是很友好的，有冲突我们diff一下，去解决不久好了嘛。
我们的口号是：
有冲突解决冲突，没有冲突就制造冲突也要去解决冲突！
最后
感谢Gayhub的吉祥物愿意出现在标题中。
向livoras大神学习，祭上一张神图供大家理解。 
一个还算有趣的前端er