We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
在我第一次接触编程的时候,学的是Pascal,在那个叫做Turbo的蓝屏编辑器里写下一些简单的流程控制去解一些简单的算法题。那时候,天还很蓝,我的代码还保存在自己电脑的文件夹里。 上了大学以后知道了github这个东西(aka: gayhub),而后又去了解了git的概念,也从字面上明白了对于一个项目的开发人员而言,版本控制是一件很重要的事情。 当有了项目经验以后,不再是自己一个人coding了,由于责任的划分、产品的迭代等方面都出现过一些小范围内毁灭性的“失误”,所以终于深刻意识到了版本控制是一件重要的事情。 目前最流行的版本控制工具有两种:svn和git。 因为一些开源社区和自身特点的原因,git似乎更受广大开发者的青睐。 (本文所介绍的工作流是借鉴livoras大神的相关issue)
svn
git
关于git的概念,大概分为以下三点:
就像图中所示,仓库有两大类:源仓库(最中间的)和开发者仓库(四周的)。 源仓库就是项目发起人所建立的仓库,其他开发者只能基于这个仓库对项目进行开发。 开发者仓库则是众多开发者们从项目发起这那里fork来的,可以在自己的主页看到这个“转发”来的仓库,相应的,开发者的commit和push操作都是基于这个克隆体来进行的。
fork
commit
push
分支在git中是一个很重要的概念(当然了,svn中也有)。 在git中,分支主要分为两种:永久性分支和临时性分支。
一般情况下就是指master和develop这两个分支,前者用于保存产品每个版本的代码,通常由develop分支合并而来;后者则是开发者的主要战场。
master
develop
根据不同的用途,可将临时性分支分为以下三种:
我喜欢把临时性分支成为备胎分支,因为她们的设定非常符合用完即走的产品理念(备胎们哭晕在仓库)。 可能你会有点不理解为什么这些分支的命运如此悲凉,那我来举个栗子 有一天,产品要求小明给主页增加一个点赞的功能,说时迟那时快,小明撸起袖子就是干
$ 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到自己的远程仓库
看到了吧,这就是临时性分支的悲惨命运。不过话说回来,为了整个项目的推进而牺牲不失为一件光荣的事情。
ok,接下来就到本文的Highlight了,一种可靠的工作流——使用git和github进行协同开发(livoras大神的 那篇文章也叫这个名字,大家可以去看看)
Highlight
github
找到源仓库并fork之,clone这个“转发”来的副本(开发者仓库)。
clone
在本地就可以进行开发啦,进入develop分支(你的主战场),并根据需求创建临时分支进行开发,最终合并到develop分支。 自己搞好以后就可以push了,但这并不是上传到源仓库,而是你的开发者仓库。
此时对于 自己刚才上传的代码,你肯定满满的自信,大概是:“卧槽我怎么这么帅真是写得一手好代码”,肯定是希望项目的发起者(管理员)将你的贡献“收录”了,这时,就需要你去提交一个pull request(江湖人称PR)。 提交之后,剩下的工作就交给管理员了。
pull request
PR
管理员看到了你的PR,可以在github上面直接review你提交的更改,下一步,他会在本地仓库输入以下命令:
$ git checkout develop $ git checkout -b kyrieliu-develop $ git pull https://github.com/kkkyrie/project.git develop //将你的代码pull到本地的测试分支中进行测试
如果管理员确定没问题,一般情况下就会接受你的PR了。 当然,可以通过两种方法接受一个PR:
$ git checkout develop $ git merge --no-ff kyrieliu-develop $ git branch -d kyrieliu-develop $ git push origin develop
通过上述的步骤,由你新加的thumbsUp.js就从你本地经历了万水千山最终到达了源仓库。
thumbsUp.js
在实际操作中,经常会出现有冲突的情况,作为一个同样遇到过冲突并且最终解决了的人,我由衷的告诉你:不要慌,出现冲突也是一件很平常的事情,实在解决不了那就无脑回滚吧!(噗哈哈哈) 如果其他开发者在你开发的过程中有上传新的代码,在你pull之前一定要先commit你本地的修改,不然可能等你pull下来以后会发现:卧槽我刚写的代码呢? 另外,个人觉得git的提示还是很友好的,有冲突我们diff一下,去解决不久好了嘛。
pull
diff
我们的口号是: 有冲突解决冲突,没有冲突就制造冲突也要去解决冲突!
向livoras大神学习,祭上一张神图供大家理解。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
写在前面
在我第一次接触编程的时候,学的是Pascal,在那个叫做Turbo的蓝屏编辑器里写下一些简单的流程控制去解一些简单的算法题。那时候,天还很蓝,我的代码还保存在自己电脑的文件夹里。
上了大学以后知道了github这个东西(aka: gayhub),而后又去了解了git的概念,也从字面上明白了对于一个项目的开发人员而言,版本控制是一件很重要的事情。
当有了项目经验以后,不再是自己一个人coding了,由于责任的划分、产品的迭代等方面都出现过一些小范围内毁灭性的“失误”,所以终于深刻意识到了版本控制是一件重要的事情。
目前最流行的版本控制工具有两种:
svn
和git
。因为一些开源社区和自身特点的原因,
git
似乎更受广大开发者的青睐。(本文所介绍的工作流是借鉴livoras大神的相关issue)
什么是
git
?关于
git
的概念,大概分为以下三点:git
”一些概念的正确打开方式
仓库
就像图中所示,仓库有两大类:源仓库(最中间的)和开发者仓库(四周的)。
源仓库就是项目发起人所建立的仓库,其他开发者只能基于这个仓库对项目进行开发。
开发者仓库则是众多开发者们从项目发起这那里
fork
来的,可以在自己的主页看到这个“转发”来的仓库,相应的,开发者的commit
和push
操作都是基于这个克隆体来进行的。分支
分支在
git
中是一个很重要的概念(当然了,svn
中也有)。在
git
中,分支主要分为两种:永久性分支和临时性分支。永久性分支
一般情况下就是指
master
和develop
这两个分支,前者用于保存产品每个版本的代码,通常由develop
分支合并而来;后者则是开发者的主要战场。临时性分支
根据不同的用途,可将临时性分支分为以下三种:
我喜欢把临时性分支成为备胎分支,因为她们的设定非常符合用完即走的产品理念(备胎们哭晕在仓库)。
可能你会有点不理解为什么这些分支的命运如此悲凉,那我来举个栗子
有一天,产品要求小明给主页增加一个点赞的功能,说时迟那时快,小明撸起袖子就是干
$ 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你提交的更改,下一步,他会在本地仓库输入以下命令:
如果管理员确定没问题,一般情况下就会接受你的PR了。
当然,可以通过两种方法接受一个PR:
通过上述的步骤,由你新加的
thumbsUp.js
就从你本地经历了万水千山最终到达了源仓库。有冲突了?莫慌!
在实际操作中,经常会出现有冲突的情况,作为一个同样遇到过冲突并且最终解决了的人,我由衷的告诉你:不要慌,出现冲突也是一件很平常的事情,实在解决不了那就无脑回滚吧!(噗哈哈哈)
如果其他开发者在你开发的过程中有上传新的代码,在你
pull
之前一定要先commit
你本地的修改,不然可能等你pull
下来以后会发现:卧槽我刚写的代码呢?另外,个人觉得
git
的提示还是很友好的,有冲突我们diff
一下,去解决不久好了嘛。最后
向livoras大神学习,祭上一张神图供大家理解。
The text was updated successfully, but these errors were encountered: