写在前面
在我第一次接触编程的时候,学的是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
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。