Skip to content
New issue

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

Git&Github Workflow #5

Open
KKKyrie opened this issue May 24, 2018 · 0 comments
Open

Git&Github Workflow #5

KKKyrie opened this issue May 24, 2018 · 0 comments
Labels

Comments

@KKKyrie
Copy link
Owner

KKKyrie commented May 24, 2018

写在前面

在我第一次接触编程的时候,学的是Pascal,在那个叫做Turbo的蓝屏编辑器里写下一些简单的流程控制去解一些简单的算法题。那时候,天还很蓝,我的代码还保存在自己电脑的文件夹里。
上了大学以后知道了github这个东西(aka: gayhub),而后又去了解了git的概念,也从字面上明白了对于一个项目的开发人员而言,版本控制是一件很重要的事情。
当有了项目经验以后,不再是自己一个人coding了,由于责任的划分、产品的迭代等方面都出现过一些小范围内毁灭性的“失误”,所以终于深刻意识到了版本控制是一件重要的事情
目前最流行的版本控制工具有两种:svngit
因为一些开源社区和自身特点的原因,git似乎更受广大开发者的青睐。
(本文所介绍的工作流是借鉴livoras大神的相关issue

什么是git

关于git的概念,大概分为以下三点:

  1. 打开浏览器
  2. 在地址栏输入“baidu.com”
  3. 搜索:“什么是git

一些概念的正确打开方式

仓库

github的仓库
就像图中所示,仓库有两大类:源仓库(最中间的)和开发者仓库(四周的)。
源仓库就是项目发起人所建立的仓库,其他开发者只能基于这个仓库对项目进行开发。
开发者仓库则是众多开发者们从项目发起这那里fork来的,可以在自己的主页看到这个“转发”来的仓库,相应的,开发者的commitpush操作都是基于这个克隆体来进行的。

分支

分支在git中是一个很重要的概念(当然了,svn中也有)。
git中,分支主要分为两种:永久性分支和临时性分支。

永久性分支

一般情况下就是指masterdevelop这两个分支,前者用于保存产品每个版本的代码,通常由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了,一种可靠的工作流——使用gitgithub进行协同开发(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:

  1. 直接在github上接受
  2. 命令行:
$ 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一下,去解决不久好了嘛。

我们的口号是:
有冲突解决冲突,没有冲突就制造冲突也要去解决冲突!

最后

向livoras大神学习,祭上一张神图供大家理解。
git协同开发

@KKKyrie KKKyrie changed the title My Git Workflow Git&Github 工作流 May 24, 2018
@KKKyrie KKKyrie changed the title Git&Github 工作流 Git&Github Workflow Mar 7, 2019
@KKKyrie KKKyrie added the Git label Mar 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant