赞
踩
全文约9300字,阅读大概需要20分钟(阅读速度按500字/分钟计算)
目录
我曾在GitHub上摸爬滚打了很久,还是撞得鼻青脸肿,主要是对于其官网英文页面不是很适应,对里面的很多新概念似懂非懂,网上的教程比较混乱,不成体系。偶然的一次机会,我看到了大佬「stormzhang」写的GitHub入门文章(stormzhang是其通用网名,知乎专栏同名,微信公众号同名),个人觉得其内容自成体系,对新手友好,因此全文拜读。
【目前 stormzhang 已经把他的文章整理为电子书,关注其微信公众号回复「GitHub」即可下载】
这篇博客是我整理大佬的文章,结合自己的情况写下的总结。
首先列出自己参考的文章链接:
首先是「stormzhang」的系列的第一篇知乎专栏文章初识GitHub。
然后是他的文章系列的第二篇加入GitHub。这篇文章尾部提供了Markdown语法的新手指南。
系列的第三篇Git速成。注意这篇文章中的几个平台Git安装方法。需要尤其熟悉其中的Git命令列表部分。
这里是他的一篇终端软件的小介绍,不重要,可以看看,终端小介绍。
系列第四篇向GitHub提交代码。
下面是自己对这位作者(stormzhang)的文章的进一步总结,亲手敲出了每一条命令和每一个字(毕竟自己把知识点敲出来印象更为深刻,也为了防止原作者删了文章而找不到了,也为了以后工作时的复习)。
2008年4月10日,GitHub正式成立,地址是:GitHub官网。
确切地说,它是一家公司,位于旧金山,创办者:Chris Wanstrath,PJ Hyett和Tom PrestonWerner。
目前是全球最大的开源社区(已经被微软收购,对于开源世界来说不是一个好消息)。
当初自己也看过廖雪峰的教程,总是看完就会忘记,自己动手敲,用轻松易懂的语言把它讲出来,然后多加练习才能真的掌握。
Git是一款免费的、开源的分布式版本管理系统,由著名的Linux开发者Linus Torvalds开发。
之前比较流行的版本控制系统有SVN,而Git是新时代的产物,SVN现在来说有些落伍。
GitHub是一个平台,提供基于Git的版本托管服务。
也就是说,现在GitHub上托管的所有项目代码都是基于Git技术来进行版本控制的,即Git只是GitHub平台上用来管理项目的一个工具而已。GitHub在发展过程中还有很多其他功能。
全球顶级科技公司纷纷加入GitHub,并贡献他们自己的项目代码:
全球顶级开源项目优先选择在GitHub上开源:
全球顶级编程大牛加入GitHub:
其他不一一列举,在Github上还有很多活跃的Google、阿里、微软等大公司的员工,在这里可以接触到全球顶级大牛!
开源社区流行一句话,「不要重复造轮子」,说的就是不要重复地做别人已经做过的工作。
因为你现在想做的东西,有极大的概率已经有人实现了,而且实现的方式比你的好N倍。
其实正是因为开源社区的贡献,现在的软件开发才会越来越容易、效率越来越高,我们越来越能够把我们的精力放在真正需要创造力的地方。
试想你在做项目的时候,如果每一块模板都要自己去写,比如网络库、图片加载库、ORM库等,自己写的好不好是一回事,时间与资源是很大的成本。
对于大公司来说,可能会选择花费人力与资源去发明一套自己的轮子,但是对于大部分互联网创业公司来说,时间就是一切,效率就是生命。
自己在使用开源项目的时候,可以学习他们优秀的设计思想、实现方式,这是最好的学习资料,是提示自己能力的绝佳方式!
这里不仅仅是指团队开发项目中的代码协作,任何能够通过多人协作的项目都可以借助GitHub提升效率。
如果你要发起一个项目,比如翻译一本书,觉得一个人的时间和精力不够,那么可以把这个项目放在GitHub上,让有兴趣的人参与进来,大家可以在任何时间任何地点为此项目做贡献,然后可以互相审核、合并。
简直不要太棒!
比如,现在有些博客是基于GitHub Pages来搭建,你可以随心所欲定制自己的样式,可以给自己的博客买一个逼格高的域名。
不需要忍受各大博客网站的约束与各式各样的广告了!
如果你喜欢基于Markdown语法来写作,并准备出版书籍,那么GitHub和Gitbook就很适合你,尤其适合技术人!
如果你有一个活跃的GitHub账号,上面有不错的开源的项目,还经常给别的开源项目提问题,push代码,那么你找工作的时候就有巨大的优势。
很多IT公司看重GitHub账号,某种意义上GitHub可以算作是你的简历。而且不仅国内,很多国外的科技公司都会通过GitHub来寻找优秀的人才。
其实还有很多很多有趣的事情等待你去挖掘!
不需要翻墙。印象中GitHub的访问速度一直都是有些慢的,其实很正常,其公司在美国旧金山。GitHub影响力很大,每天都会被无数黑客攻击,所以偶尔会有宕机无法访问的时候,但是不会被封(不过2020年2-3月份期间经常上不去,可以百度查询相关原因)。
接下来进入正文:
这个应该没啥说的,需要填用户名、邮箱、密码,值得一提的用户名请不要那么随便,最好取的这个名字就是你以后常用的用户名了,也强烈建议你各大社交账号都用一样的用户名,这样识别度较高,而且这个用户名以后在 GitHub 搭建博客的时候默认给你生成的博客地址就是 http://username.github.io ,所以给自己取个好点的用户名吧。
比如我的是keneathguo。
那么这是什么意思呢? GitHub账户有两种,一种是公开的,这种是免费的,就是说你创建的项目是开放的,所有人都能看得到;另一种是私有的,这种是收费的,这种一般是很多企业在用GitHub的私有仓库在托管自己的仓库,这也是GitHub的一种盈利模式。
对于我们个人使用而言,直接默认选择公开的就行了。
注册成功之后,来到GitHub的主页面来。这里使用「stormzhang」老哥的图片来做说明:
但是咱们新注册的账号里几乎是一片空白,还没有参与什么项目,没有关注的人,所以几乎什么都没有,只有一个导航栏。
导航栏:从左到右依次是「Github主页按钮」、「搜索框」、「PR」、「Issues」、「Gist」、(这些概念后面详细说明)「消息提醒」、「创建项目按钮」、「我的账号相关」。
我的Timeline:这部分就理解为「我的关注」,就是你关注的人的活动会出现在这里。比如如果你们关注我了,那么以后我star、fork了某些项目都会出现在你的时间线里。
我的项目:自己创建、参与、改造的项目,快捷访问的入口。
点击最右边的「我的账号相关」,再选择 「Your profile」菜单进入你的个人Github主页
还是以「stormzhang」的Github主页为例:
新用户的主页是一片空白。图中标注的非常详细,理解每一部分都是展示什么内容的即可。
新注册完了之后,一般都需要浏览一下设置。
尽管是全英文界面(如果使用谷歌浏览器,可以有网页翻译帮助理解),但是尽量不要抵触它,要从内心深处去尝试接受它,无非就是一些概念换了个英文的壳子而已。
由于是刚开始接触,所以不妨多花些时间来泡在每一项设置上,尝试去理解开发者为什么要设置这些选项,是为了应对哪些风险呢?这些措施可不可以为以后我们自己开发网站提供经验和思路?这些都是我们值得花时间去接受新事物的原因。
第一步完善自己的信息,点击如下Settings菜单:
到设置页面来设置一些信息:
头像、Name建议设置一个常用的,要有识别性,公开的邮箱也设置一个,便于技术人的交流。
这样其他技术人员、企业、猎头可以通过这个公开邮箱去联系你。
个人觉得最好不要放QQ邮箱,哪怕申请一个谷歌邮箱然后转发到QQ邮箱逼格也高一些呀。
另笔者近期实测,谷歌邮箱Gmail可以直接在网页申请,我的号码是183开头移动号,可以接收短信验证码(听说有些手机号解接收不了验证码?)。
也可以弄个163、foxmail邮箱。其实如果花上一个下午的时间去好好了解这些邮箱服务商之间的不同是很有收获的,而且最好把一个邮箱设置为你的主邮箱,其他的邮箱邮件都转发到主邮箱里。要养成常看主邮箱的习惯。
Github上有一些概念是我们经常会遇到的,整理如下:(其实就是一个熟悉程度的问题,经常玩GitHub就慢慢熟悉了)
仓库的意思,即你的项目,在Github平台上,属于云端或者服务器端的仓库。
你要在Github上开源一个项目,那就要新建一个Repository,项目和Repository是一一对应的。
问题的意思。举个例子,你开源了一个项目,别人发现你的项目中有bug,或者哪些地方做的不够好,他就可以给你提个Issue,即问题,大家都给你提问题,提的问题多了,也就是 Issues。
然后你看到了这些问题,就可以逐个去修复,修复完了就可以一个个的close掉。
这个就是给项目「点赞」,也可以理解为「收藏」,因为Star的项目被系统记录下来了,你可以随时查看。但是Github上获得Star比微博知乎要难很多。
笔者认为,最大原因就是Github是技术人的圈子,大家技术水平都很高,所以获得点赞的门槛比较高。
英文中的“叉子”,可以翻译成「分叉」。
什么意思呢? 你开源了一个项目,别人想在你这个项目的基础上做些改进,然后应用到自己的项目中,这个时候他就可以 Fork 你的项目,然后他的Github主页上就多了一个项目,只不过这个项目是基于你的项目基础(本质上就是在原来项目的基础上新建了一个分支,分支的概念在后面讲Git时候说),他可以随心所欲地改进、应用,但是不会影响原有项目地代码与结构(其实就是克隆了一份,然后改造克隆的那份)。
仔细想想,我们如果想使用某个开源项目,是不是就是这样 Fork,然后加以改造就行了呢?
发起请求,这个概念是基于Fork的。
还是上面那个例子,如果别人在你的基础上做了改进,然后觉得改的很不错,这些改进应该让更多的人获益,于是想把自己的改进合并到原来项目里,这时他就可以发起一个 Pull Request (简称PR),原有项目创建者,也就是你,就会收到这个请求(PR),这时你可以仔细 Review 他的改进(代码),并且测试觉得OK了,就会接收他的PR,并合并进去,然后他做的改进原有的项目就会拥有了。
仔细想想,这不就是广发开发者改进Linux、Android等开源项目的过程吗?
这个好理解,就是「观察」。如果你Watch了某个项目,那么以后只要这个项目有任何更新,你都会第一时间收到关于这个项目的通知提醒。
体会一下跟 Star 的区别。
有些时候你没有项目可以开源,只是想简单的分享一些代码片段,那么就使用Gist吧!
点击顶部导航栏的 「+ 」可以快速创建一个项目,如下图:
这里就是创建一个新的项目,需要填写如上几部分:项目名、项目描述与简单的介绍。
你不付费就没法选择私有的,所以接着只能选择Public的,然后勾选「Initialize this repository with a README」。
这样就拥有了你的第一个GitHub项目:
可以看到这个项目只包含了一个 README.md 文件,但是它已经是一个完整的Git仓库了。
你可以对它进行一些操作,比如Watch、Star、Fork,还可以Clone或者下载下来。
关于 README.md,GitHub上所有关于项目的详细介绍以及Wiki都是基于Markdown语法的,之后在GitHub上搭建博客,写博客也是如此。
关于Matkdown语法的推荐一篇文章:
之前的篇幅介绍过,GitHub是基于Git的,也就是说Git是基础,第三部分是介绍最基本的、最常用的Git知识,很快可以入门。
Git是Linux发明者Linus开发的一款新时代的版本控制系统。
我们在软件开发过程中对于源代码的管理是很重要的,比如为了防止代码的丢失,肯定本地机器和远程服务器都要存放一份,而且要有一套机制让本地可以和远程同步;
又比如开发一个项目经常是好几个人做同一个项目,都要对一份代码做更改,这个时候需要大家互不影响,又需要各自可以同步别人的代码;
又比如我们开发的时候难免会有bug,甚至有时候刚发布的功能就出现了严重的bug,这个时候就需要紧急对代码进行还原;
又比如随着我们版本迭代的功能越来越多,但是我们需要清楚的知道历史每一个版本的代码更改记录,甚至知道每个人历史提交代码的情况;
等等等等类似上述的情况,这些都是版本控制系统能解决的问题。
所以说,版本控制是一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
对于软件开发领域来说版本控制是最重要的一环,而Git毫无疑问是当下最流行、最好用的版本控制系统。
Git是一个版本控制系统,也是一个工具,跟Java类似,使用之前必须得先下载安装,所以第一步是要安装。
Mac上自带Git,Windows系统要自己安装。
Mac:https://sourceforge.net/projects/git-osx-installer/
Windows:https://git-for-windows.github.io/
Linux:apt-get install git
安装好Git之后,怎么学习是个问题,其实关于Git有很多图形化的软件可以操作,但是本人感觉从命令行开始学习理解会更好。
虽然没接触过命令行的人可能会很抵触,但是只有一开始学习命令行,之后你对Git的每一步操作才能更好理解其意义。
等到熟练之后我们再用各种图形化的软件去操作是完全没问题的。
如何判断Git有没有安装成功?在Git Bash命令行列里输入git,如果出现以下提示就说明成功了。
Git所有的操作命令都要以git开头,上面列举了最常用的Git命令,紧接着会有一句英文解释这个命令的意义,都不是很难的单词,不妨深入钻研一下每个命令的大概意思。
不过没有动手操作还是不好理解,接下来用具体操作来体会这些命令。
提醒:在进行任何Git操作之前都需要在Git Bash中切换到Git仓库目录,也就是先要切换到项目的文件夹目录下。
Windows用户直接手动建立一个项目文件夹(我在D盘下建立了GitTest文件夹作为测试),在文件夹里新建一个文件a.md(Markdown格式文件)。
Linux用户用命令来建立:
mkdir test (创建文件夹test)
cd test (切换到test目录)
touch a.md (新建a.md文件)
建立好之后,先随便操作一个命令,比如 git status ,可以看到如下提示(颜色无所谓):
意思就是当前这个文件夹还不是一个Git仓库。
使用 git init 来初始化这个文件夹使其成为一个git仓库:
可以看到初始化成功,这时候GitTest文件夹就是一个git仓库了。
紧接着输入 git status 命令,会有以下提示:
默认就是在master分支,分支的概念在后面有进一步的解释。
这时最主要的提示就是a.md文件时Untracked files,就是说a.md这个文件还没被跟踪,还没有提交到git仓库里,而且提示你可以用git add <file> 去操作你想要提交的文件
git status 这个命令顾名思义就是查看状态,这个命令可以算是使用最频繁的一个命令了,建议没事就输入一下这个命令,来查看你当前git仓库的一些状态。
git add
上面提示 a.md 文件还没提交到仓库里,这时可以随便编辑一下 a.md 文件,然后输入 git add a.md ,再输入 git status:
此时提示以下文件Changes to be committed,意思就是 a.md 文件等待被提交。
当然你可以使用 git rm --cached 这个命令去移除这个缓存。
git commit
接着我们输入 git commit -m ‘first commit’,这个命令中 commit 就是提交的意思,-m 代表提交时的备注信息,即对这次提交的说明,执行了以上命令代表我们已经正式进行了第一次提交。
这时再输入git status,会提示 nothing to commit。
输入 git log 命令,会看到如下:
git log 命令可以查看所有产生的commit记录,所以可以看到已经产生了一条commit记录,提交时的备注信息就叫“first commit”。
注意:git add & git commit
看到这里也许会有疑问,我想要提交直接进行commit不就行了吗,为什么要先add一次呢?
首先git add 时先把改动添加到一个「暂存区」,你可以理解为一个缓存区域,临时保存你的改动,而git commit才是最后的提交。这样的好处就是防止误提交。
当然也有办法把这两步合并成一步,不过后面再介绍,建议新手按部就班的一步步来。
git branch
branch就是“分支”的意思。分支的概念很重要,尤其是团队协作开发的时候。
假设两个人都在做同一个项目,这个时候分支就是保证两人能协同合作的最大利器。
举个例子,A,B两人都在做同一个项目,但是是不同的模块。这个时候A新建了一个分支叫a,B新建了一个分支叫b,这样A,B做的所有代码改动都各自在各自的分支,互不影响,等到俩人都把各自的模块做完了,最后再统一把分支合并起来。
执行了 git init ,初始化git仓库之后会默认生成一个主分支master,也是你所在的默认分支,也基本是实际开发正式环境下的分支,一般情况下master分支不会轻易直接再上面操作的,你们可以输入git branch 查看当前分支情况:
如果我们想在此基础上新建一个分支呢? 只需执行命令 git branch a 就新建了一个名字叫 a 的分支。
而且这时候分支a和分支master是一模一样的内容,我们再输入 git branch 查看当前的分支情况:
但是可以看到master分支前有个 * 号,即虽然新建了一个 a 的分支,但是当前所在的分支还是在master上。
如果我们想在a分支上进行开发,首先要切换到a分支上去,所以使用以下命令切换分支:
git checkout a
执行之后,再输入 git branch 查看分支情况;
可以看到当前我们所在分支已经到a上去了。也就是说,这时本地文件夹里的内容其实属于a 分支,A同学就可以在自己的本地上在他新建的a分支去进行代码改动了。
也许会有人要说,我要先新建再切换,太麻烦,有没有一步到位的命令?有!
git checkout -b a
这个命令就是新建一个a分支,并且自动切换到a分支。
git merge
A同学在a分支写了自己的代码,终于完工了他的功能,并且测试也都ok了,准备上线,这时候就需要把他本地的代码合并到GitHub上的主分支master上来,然后发布。
git merge 就是合并分支用到的命令.面对这种情况,需要做两步:
第一步是切换到master分支,如果你已经在了就不用切换了;
第二步是执行 git merge a,意思就是把a分支的代码合并过来。
不出意外的话,这时a分支的代码就顺利合并到master分支来了。但是在实际情况中,会经常出现“意外”,也就是说经常会因为出现冲突而导致合并失败。这一点,后面讲。
git branch -d
有新建分支,就有删除分支。假如这个分支新建错了,或者a分支的代码已经顺利合并到master分支来了,那么a分支算是没用了(已经测试完的代码就合并到正式程序中去了),需要删除,这时执行git branch -d a就可以把a分支删除了。
git branch -D
有时候会删除失败,比如如果a分支的代码还没有合并到master,你执行 git branch -d a是删除不了的,它会智能提示你a分支还要未合并的代码,但是如果你非要删除,那就执行 git branch -D a就可以强制删除a分支。
git tag
我们在客户端开发的时候经常会有版本的概念,比如v1.0、v1.1之类的。
不同的版本肯定对应不同的代码,所以我们一般要给代码加上标签,这样假设v1.1版本出了一个新bug,但是又不知道v1.0是否有这个bug,有了标签就可以顺利切换到v1.0的代码,重新打个包测试了。
所以如果想要新建一个标签很简单,比如 git tag v1.0 就代表我在当前代码状态下新建了一个v1.0的标签,输入git tag可以查看历史tag记录。
如果建立了两个标签,v1.0和v1.1,需要切换的话,执行命令git checkout v1.0,这样就顺利的切换到v1.0 tag的代码状态了。
以上是一些最基本的Git操作,而且全是在本地环境进行操作的,完全没有涉及远程仓库,下一部分将以远程GitHub仓库为例,讲解下本地如何跟远程仓库一起同步协作。
这部分开始来介绍如何跟远程仓库一起协作,来尝试如何向GitHub上提交自己的代码!
当我们拥有一个GitHub账号之后,就可以自由的Clone或者下载其他项目,也可以创建自己的项目,但是没办法提交代码。
仔细想想会理解,肯定不能随意就能提交代码的,如果随意可以提交代码,那么GitHub上的项目就会乱套。
所以在提交代码之前一定是需要某种授权的,而GitHub上一般都是基于SSH授权的。
那么什么是SSH呢?
简单点说,SSH是一种网络协议,用于计算机之间的加密登录。目前是每一台Linux电脑的标准配置。
而大多数Git服务器都会选择使用SSH公钥来进行授权,所以想要在GitHub提交代码的第一步就是要先添加SSH key配置。
Linux和Mac都是默认安装了SSH,而Windows系统安装了Git Bash也是带了SSH的。我们可以在终端(Windows下在Git Bash里)输入ssh 如果出现以下提示证明你本机已经安装了SSH,否则请自行搜索安装下:
紧接着输入 ssh-keygen -t rsa ,什么意思呢?就是指定rsa算法生成密钥,接着连续三个回车键(不需要输入密码),然后就会生成两个文件 id_rsa 和 id_rsa.pub ,而 id_rsa是密钥,id_rsa.pub 就是公钥。
这两个文件默认在如下目录里生成;
Linux/Mac系统在 ~/.ssh
Windows在 C:\Users\username\.ssh
都是隐藏文件,相信大家都有办法查看的。(Windows系统之直接提供查看隐藏文件选项)
接下来要做的就是把id_rsa.pub的内容添加到 GitHub上。
这样你本地的id_rsa密钥跟GitHub上的id_rsa.pub公钥进行配对,授权成功才可以提交代码。
第一步先在GitHub上的设置页面,点击最左侧「 SSH and GPG keys」:
然后点击右上角的「 New SSH key」 按钮;
需要做就是在Key那栏把 id_rsa.pub公钥文件里的内容复制粘贴进去就可以了(示例中为了安全所以打码),Title那栏不需要写,点击 「Add SSH key」 按钮就可以了。
提示:如何查看 id_rsa.pub文件的内容?
Linux/Mac用户执行命令:
cd ~/.ssh
cat id_rsa.pub
Windows用户,设置显示隐藏文件,使用Notepad++或者EditPlus或Sublime打开复制就可以了。
SSH key添加成功之后,输入 ssh -T git@github.com 进行测试,如果出现以下提示说明添加成功:
在提交代码之前我们先要了解两个命令,也是之前留下了的问题,这两个命令需要跟远程仓库配合。
Push:直译过来就是「推」的意思,什么意思呢?就是说,如果你本地代码有更新了,那么就需要把本地代码推到远程仓库,这样本地仓库跟远程仓库就可以保持同步了。
代码示例:git push origin master
意思就是把本地代码推到远程master分支。
Pull:直译过来就是「拉」的意思,如果别人提交代码到远程仓库,这个时候你需要把远程仓库的最新代码拉下来,然后保证两端代码的同步。
代码示例:git pull origin master
意思就是把远程最新的代码更新到本地。
一般我们在push之前都会先pull,这样不容易冲突。
添加SSH key成功之后,我们就有权限向GitHub上我们自己的项目提交代码了,提交代码有两种方法:
我们以我在GitHub上创建的test项目为例,执行如下命令(注意,需要先在本地建立一个文件夹用来放置项目,然后在该文件夹内用Git Bash打开,执行命令):
git clone git@github.com:KeneathGuo/test.git
这样就把test项目clone到了本地,我们可以把clone理解为高级点的复制,这时候该项目本身就已经是一个git仓库了,不需要执行git init进行初始化,而且甚至都已经关联好了远程仓库,我们只需要在这个test目录下任意修改或者添加文件,然后进行commit,之后就可以执行:
git push origin master
进行代码提交,这是最简单方便的一种方式。
至于怎样获取某个项目的仓库地址呢?如下图(这几天GitHub忽然又上不去了,所以用了大佬的图):
如果我们本地已经有一个完整的git仓库,并且已经进行了很多次commit,这个时候第一种方法就不适合了。
假设我们本地有个test2的项目,我们需要的是在GitHub上建一个test的项目,然后把本地test2上所有代码的commit记录提交到GitHub上的test项目。
第一步就是在GitHub上建一个test项目,这个很简单。
第二步是把本地test2项目与GitHub上的test项目进行关联,切换到test2目录,执行如下命令:
git remote add origin git@github.com:KeneathGuo/test.git
什么意思?就是添加一个远程仓库,它的地址是 git@github.com:KeneathGuo/test.git ,而 origin是给这个项目的远程仓库起的名字。
这个名字可以随便取,只是大家默认只有一个远程仓库时名字就是origin。
为什么要给远程仓库取名字?因为我们可能一个项目有多个远程仓库,比如GitHub一个,比如公司一个,这样的话提交到不同的远程仓库就需要指定不同的仓库名字了。
查看我们当前项目有哪些远程仓库时可以执行如下命令;
git remote -v
接下来,我们本地的仓库就可以向远程仓库进行代码提交了:
git push origin master
就是默认向GitHub上的test目录提交了代码,而这个代码是在master分支。
当然,也可以提交到指定的分支,这一点之后再讲。
提醒:提交代码之前要设置一下自己的用户名和邮箱,因为这些信息会出现在所有的commit记录里,执行以下命令就可以设置;
git config --global user.name "KeneathGuo"
git config --global user.email "keneathguo@gmail.com"
通过以上的介绍,我们终于对GitHub的基础用法有了了解。
但是还有很多很多细节等待我们去深挖,比如分支的高级理解和使用,比如git的其他高级配置,比如怎样向一些开源项目贡献代码,发起Pull Request等等,有机会的话以后慢慢深挖。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。