转载自https://www.zhihu.com/question/20070065
好吧,我相信看到这里你已经晕了,这也是我一开始看那些所谓经典教程的感受。写这些教程的人都是几年以上的程序员呀,他们往往直接就告诉你所有命令的含义或者整个体系。Git 是由 Linux 之父 Linus Tovalds 为了更好地管理linux内核开发而创立的分布式版本控制/软件配置管理软件。
专家盲点(expert blind spot)就是对一个事物知道的越多,就越发不记得“不知道这个事”的情形。
所以不是程序猿可以用这个来做什么呢?Do whatever you want.
一个有自己域名的独立博客,是不是很帅?!
GitHub本身提供免费的托管服务,又提供了贴心的 Pages 功能,可以绑定你自己的域名,免费、高效、不限流量,做一个个人页面绰绰有余。
Jekyll 的教程和我自己的博客会稍后放出。。(先给自己挖个坑)
6、用GitHub协作翻译
苹果官方发布的各种官方手册,比如最近开源的 Swift numbbbbb/the-swift-programming-language-in-chinese · GitHub 就是国内一个自发组织起来的团队,30多个人用9天时间即将翻译和校对工作全部完成,他们每人都还有自己的事情,上班、上线、创业,这么大的工作量在以往简直是不可能完成的任务!
7、项目管理
GitHub最初是为了开发的管理而生,当然也就具备了项目管理的潜质,特别是与开发密切联系的项目中,它的优势尽显。比如这篇文章介绍了如何使用GitHub结合 Trello 等其它工具进行项目管理:使用GitHub进行团队合作。当然,GitHub还是很偏重开发的管理,一般的项目管理还是适合使用 wortile 之类的产品。
GitHub上的代码无法造假,也容易通过你关注的项目来了解你的知识面的宽度与深度。现在越来越多知名公司活跃在GitHub,发布开源库并招募各类人才,例如:Facebook、Twitter、Yahoo ...
开始有了第三方网站提供基于GitHub的人才招聘服务,例如:
3、在线交互学习 github 的网站Learn Git Branching 这个也很好玩~
4、[GitHub自身的官方博客](The GitHub Blog · GitHub)
5、 git-flow 备忘清单鉴于网上目前的教材都太落后,github for windows已经更新了多个版本,好多界面都发生了变化,所以来写这个教程。目的是为了帮助和我一样初学github,但是苦于找不到教程的同学,为了写最详细的教程。配备了大量的图文介绍。该教程是基于GitHub for windows (3.0.17.0)
说到什么事github,我们先看wikipedia的描述“GitHub是一个利用Git进行版本控制、专门用于存放软件代码与内容的共享虚拟主机服务。它由GitHub公司(曾称Logical Awesome)的开发者Chris Wanstrath、PJ Hyett和Tom Preston-Werner使用Ruby on Rails编写而成。”
准备工作准备工作都完了,我们开始正式学习。^_^
创建第一个代码库github for windows的界面非常清爽,的确符合geek的性质,个人表示非常喜欢。 我们来建立第一个仓库,点击左上角的+号,初次建立他会有一圈圈的涟漪,非常漂亮哦。 打开之后有三个选项,Add,Create,Clone。 我们分别来介绍一下这三个功能。
如果本地有工程,就可以使用Add添加
这个功能其实最好理解了,克隆这名字通俗易懂好理解。 如何使用Clone功能呢? 就是将在浏览器上已经创建好的项目导入到本地,换句话说就是下载到本地。
创建一个代码库, Name填写你的仓库名字。Local path写你将要保存在本地路径。
我们主要从这个功能开始github之旅。 我们在这里填写First,来创建第一个我们自己的repoeitory。
我们来找到刚刚创建的代码库在本地的位置。就是刚刚在local path的地址路径,当然如果你忘了,请右键点击First。
此时的github就会变成这个样子(Changs):
你会发现此时github会出现刚刚编辑的内容。
我们这里只选择第一个修改对象,也就是这个是测试文本就行修改。summer我们填写为第一次修改,Description我们填写为增加了这个是测试文本的内容,之后点击Commit to master。
切换到History目录下 我们会发现他改变了。 这次我们把你好进行添加。
在History目录下发生了这样的改变。会在History目录下形成一天时间线,来指出每一次的修改标题和内容,同时会把修改的内容用绿色标识标出。 我们打开本地的文本,删除刚刚添加的第一行这个是测试文本。
此时你就会发现github发生了变化。 此时的红色标识标识删除。我们写好Summer和Description并点击Commit to master。 这样我们就删除了第一行。同时在History目录下又多了一条时间轴。
这样我们就完成了删除。
上传与同步此时,当我们打开github网页,就会发现此时你的修改的内容并没有出现在这里。这是因为你没有进行同步,仅仅是在本地就行了修改。此时我们仅仅需要点击右上角的publish
此时你就会本地内容已经上传到网页上。
当你的代码库上传后就会发现,原来的publish以及变为了Sync。 点击Sync同步代码库!
我们创建第一个分支取名为new masterh,点击Create new branch创建第一个分支。
我们发现此时的分支已经切换到了我们刚刚创建的分支new masterch 。
我们来修改new masterch分支上的内容。 我们仍旧打开FirstDemo.txt进行编辑。输入以下内容
创建的第一个分支。
打开github进行,填写Summary和Description
之后我们点击Commit to new-master在History目录下,我们可以看到会有两条主线,分别是master和new-master并且在new-master的分支下又一个蓝色的实线空心圈和一个虚线空心圈。
实线圈表示当前的节点,空心圈表示下一次修改时的节点。
红线标示的部分就是当前的分支
点击红色划线部分就会出现分支的列表
我们点击master就会切换到master分支。
这个操作和同步仓库是一个操作,点击Publish/Sync上传或同步分支。
删除分支首先要把分支切换到你要删除的分支下,如我们要删除new master,将分支切换到new master
点击右上角齿轮就会出现Delete new master 点击Delete new master就会弹出一个对话框,询问删除的内容。
第一个yes ,Delete both是将本地与网页全部删除;
第二个Delete local only仅仅是删除本地。
第三个是取消。
将一个分支与master分支进行合并。 我们首先把分支切换到master下,点击Update from new-branch进行分支的合并。
此时我们查看history目录下就会
GitHub Flow是一个轻量级的,基于分支的工作流程,支持团队和部署在那里的定期做项目。
在我们的队友添加一个写的权限,这样我们的队友才能很好的修改代码。 我们打开网页上的GitHub,点击settings,
之后我们找到collaborators,这里会让我们验证密码,之后就有添加合作者的选项。
这样我们就能添加我们的小伙伴了! 这样我们就添加了新的小伙伴,新的小伙伴有着同样的权限去修改和管理代码。 此时我们就会看到我的小伙伴wevan的github主页上就会出现关于我创建的First的各种通知。
在我们创建一个叫add new function的分支。
创建一个分支 Create a branch 当你工作的一个项目,你会在任何给定的时间有一堆不同的功能或正在进行的想法 - 其中一些是蓄势待发,而另一些则不是。分支的存在是为了帮助你管理这个工作流程。 When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. 当您在项目中创建一个分支,你创造一个环境,在那里你可以尝试新的想法。你让一个分支的更改不会影响主分支,让你可以自由进行实验,并提交更改,在你的分支将不会被合并,直到它准备好知识安全的人所正在与合作进行审查。 When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect the master branch, so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone you're collaborating with. ProTip 分支在Git中是一个核心概念,整个GitHub的流量是基于它。这里只有一个规则:在任何主分支总是部署。 Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable. 正因为如此,这是非常重要的一个功能或修复工作时,你的新分支关老爷的创建。您的分支名应该是描述(例如,重构的身份验证,用户的内容缓存键,使视网膜-化身),以便其他人可以看到正在处理。 Because of this, it's extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.来自GitHub Flow
我们首先把分支切换到新的分支上add new function
修改新的版本
填写好新的Summary和Description,提交新的版本并同步。 这样小伙伴登陆到GitHub上就看到了就可以清楚的看到一切的修改。
添加提交 Add commits 一旦你的分支已经建立,现在是时候开始进行更改。无论何时添加,编辑或删除一个文件,你作出承诺,并将其添加到您的分支。提交加入这一过程保持你的进步轨迹,你在一个特性分支工作。 Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch. 还承诺创建工作的透明历史,其他人可以按照理解你做了什么,以及为什么。每次提交都有一个关联的提交信息,这是解释为什么一个特定的变化作出了说明。此外,每次提交被认为是变革的一个独立单元。这使您可以回滚的变化,如果发现错误,或者如果你决定在一个不同的方向前进。 Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction. ProTip
提交信息是重要的,特别是因为Git跟踪更改,然后将它们显示为承诺一旦他们推到服务器。通过字迹清晰提交信息,你可以更容易为其他人跟着,并提供反馈。 Commit messages are important, especially since Git tracks your changes and then displays them as commits once they're pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.来自GitHub Flow
这个是整个流程中比较关键的一步,发布Pull Request。
点击客户端或者网页上的Pull Request发布。 我们这里点击Pull Request
我们填写好必要的说明性文字 点击Send Pull Request 他既然让我们到GitHub上看,我们就听他的,点击,进入。
我们发现小伙伴已经在下面留言了!
你的小伙伴开始对你的代码讨论,修改,迭代。
部署讨论和审查你的代码 Discuss and review your code 一旦拉入请求已被打开,人或团队审查您的变化可能有疑问或意见。也许编码风格不匹配项目的指导方针,改变缺少单元测试,或者也许一切看起来不错,道具都是为了。引入请求旨在鼓励并捕获这种类型的对话。 Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation. 您还可以继续推送到你的分支在你提交的讨论和反馈光。如果有人评论说,你忘了做某件事,或者如果在代码中的错误,你可以在你的分支修复它,推高的变化。GitHub上会显示新的提交和其他任何意见,你可能会收到统一拉请求视图。 You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
ProTip 拉请求的意见都写在降价,所以你可以插入图片和表情符,使用预先格式化的文本块,等轻质格式。 Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.
合并部署 Deploy 一旦你拉的请求进行了审查和部门通过你的测试,您可以部署您的更改,以验证他们的生产。如果你的分支造成的问题,您可以通过部署现有的主投产回滚 Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
合并分支我们之前已经说过,这里就不再赘述。
合并 Merge 现在,您的更改在生产中得到了验证,现在是时候你的代码合并到主分支。 Now that your changes have been verified in production, it is time to merge your code into the master branch. 合并后,引入请求保护的历史变迁到您的代码记录。因为他们是搜索的,他们不让任何人回去的时间理解为什么以及如何决定了。 Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.
ProTip 通过将某些关键字到您的拉请求的文本,你可以用代码相关联的问题。当你拉入请求合并,相关问题也将被关闭。例如,输入短语关闭#32将关闭在仓库中发行数量32。欲了解更多信息,请查看我们的帮助文章。 By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository. For more information, check out our help article.
在上述的几个教程里讲解了一些Github的基础使用,现在开始讲解一些使用技巧。
在github页面上是没有搜索的按钮,如何搜索呢。 在网页上按T就会出现。 这样我们就能很方便的查找到我们需要的代码了。
常常在版本描述或者pull request时我们需要对伙伴的代码进行一下评论与说明,光是文字有点很死板,其实github给我有emoji,如何使用呢?其实很简单,只需要冒号就可以 :
这样我们就可以看到emoji表情,当然默认会显示五个常用的,你也可以继续敲下emoji的名字,出现更多(这里有所有的表情)。
有些在github中的文件我们是不想上传的,我们如何过滤掉它们呢? 在github中对不想上传的文件点击右键。就会出现下面选项。 Ignore file忽略这个文件 Ignore all.txt files 忽略所有的以.txt结尾的文件 这样就可以过滤掉你不想上传的文件
如何高效的搜索一个你想要的库呢? 我们常常评判一个项目的标准有star数目,fork数目和跟新时间。 通过搜索命令
stars
stars:>1000
表示star数目大于1000。
fork
fork:>1000
表示fork数目大于1000。
语言搜索
java,html等等
综合一下就是,比如你要查找一个stars大于1000的,fork大于200的java代码。
stars:>1000 fork:>200 java
就是这样。
码字不易,终于写完了,如果觉得对你有帮助,我的目的就达到了。
谢谢
如有错误,还望指正。
不要光收藏,点个赞啊!
转载请通知作者!
谢谢!!!!!!!!!!!!!!!!!!!!
放(打)一(广)个(告)比较有意思的《GitHub - phodal/github-roam: GitHub 漫游指南》电子书,当然也是放在GitHub上的。
漫游在第547天里:phodal (Fengda Huang) · GitHub
为什么没人说Command Line???
新手都觉得command line太难,其实不然,就那么几个需要用的命令,多用几次就记熟了。记熟了不但操作极为方便,也是装X利器啊!!
跑题了。先说GitHub
请大家假设以下的情景,现在有一个项目,要有两个人来完成,小明和小红。
小明和小红一人一台电脑,分别在两个屋子里工作。
首先在GitHub上有一个原档,小明小红分别下载到自己的电脑里开始工作。
假设原文档如下str = "Hello Zhihu!"
for letter in str:
print (letter)
这时候小明说,好,我来接着写
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
小红拿到文件之后也说,好,我来接着写。
str = "Hello Zhihu!"
for letter in str:
print (letter)
str1="LiMaBianWangHong"
这个时候小明和小红是互相不知道对方在干什么的。
但是两个人必须同时完成这个coding,这个时候该怎么办呢?
没错,在GitHub上同步两人的文件。
小明先从GitHub上下载。小明一看没变化(此时小红还没上传),于是把自己的改变传上去。
此时原文档变成了name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="LiMaBianWangHong"
小红确认了code无误之后又把自己的code同步到Github上
这时小明再同步,他就会看到name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="LiMaBianWangHong"
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="ChouNv"
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="XiaoHongShiNvShen"
这时小明先上传了上去,小红一同步一看
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
<<<<<<<<<Head
Here is the original change.
str1="XiaoHongShiNvShen"
=======
Here is the modified change.
str1="ChouNv"
这个时候怎么办呢,就要手动修改。把提示的line全都删掉即可。
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="XiaoHongShiNvShen"
print("xiao ming shi sb")
讲到这里大家应该就对github有一个大致的印象了。基本就是个同步工作进程的工具。
那么实现同步都需要哪些命令行呢?其实很简单。我保证你一分钟就能记住。
小明或者小红得先看看github上有没有其他人的更新,所以他要先输入
>>> git status
这个很好理解吧,就是查看状态。
如果这时候先是说有修改过的文件,那你就要下载下来对不对啊。>>> git pull
是不是很简单,往下拉
你拉下来之后,核对了,无误,要把自己的成果发布上去,怎么弄呢?
你想象两座山之间,要传递食物,中间有个小滑索的车,你是不是先把食物放进小车里,之后把小车推到对面的山去呢?
这里也是一样的,你要先>>> git add
>>> git add xiaoming.txt
现在食物放进车里了,下一步呢?
对面的山里人可能不知道你这吃的是什么,你是不是得写个条子留个言告诉别人是什么食物啊?
>>> git commit -m "这是汉堡包"
commit不难理解吧, -m就是message的意思。是什么message呢? “这是汉堡包”
一般这里写你对文件做出了什么修改 比如
>>> git commit -m "new feature: xiao hong bian bai fu mei"
至此你应经做完全部准备工作,就差推出去了!
>>> git push origin master
push很好理解吧,origin master 代表你的权限。多用几次就熟悉了!
以后不用开网页,用terminal上传文件到github,逼格高高的!
你们如果以为我只会秀恩爱那就错了,应读者要求,最近在写一个针对小白的从0开始学习GitHub的系列,无门槛,包教包会,感兴趣的不妨看一下:
从0开始学习 GitHub 系列之「初识 GitHub」 - AndroidDeveloper - 知乎专栏
从0开始学习 GitHub 系列之「加入 GitHub」 - AndroidDeveloper - 知乎专栏
待续...
++++++++++++++++++++++++++++++++++++++++++++++++++++
我对GitHub可是真爱粉,媳妇也是写程序的,也知道GitHub,今天我发给媳妇一个链接,说你看我GitHub粉丝都涨到多少啦,媳妇一脸不屑的打开我的GitHub,然后就感动的哭了。。。
不推荐看纸质资料,git和github涉及到很强的操作性,只看资料里的讲解是完全不够的。而且就像任何一门科学一样,我们为什么要用git,git有什么好处,学会了git后如何在github上和别人collaborate,这些东西都最好有人直接告诉我们。只告诉你怎么做不告诉你为什么以及背后原理的都是在耍流氓。千万别以为学会了git就会用github,除非你只玩单机版。不fork别人的repo,也不pull request,这样还怎么愉快地同性交友?
我之前只看了廖雪峰的那个git教程,因为网上很多人推荐。但看完了对git还是一知半解,github也只会个push……之后自己用pelican做博客想放在github上,结果还是因为不懂原理结果在创建.io repo的时候把pelican的原文件都覆盖了,还不知道怎么退回到原来的版本……唉,年少无知啊。直到一个月前发现了Udacity出的这门课How to Use Git and GitHub,https://www.udacity.com/course/how-to-use-git-and-github--ud775.
这门课前两个lesson都在讲git的各种技巧,背后的概念也解释得很清楚。有了良好的git基础后lesson 3讲授如何使用github。介绍了很多在实际开发过程中遇到的问题,最典型的就是merge conflict,比如你fork了一个original repo,你在本地对local repo里little_prince.txt做了修改,push到了fork repo,但是此时original repo里的同一文件也被人做了修改。所以当你想要把自己的branch merge到 original repo的时候会有merge conflict。这种问题在collaborate过程中很常见,如何解决这种问题lesson 3里也讲得很清楚,先画概念图告诉你大致原理,然后用命令行演示给你看,非常良心。
不过只有英文字幕,如果觉得有困难的话,可以参考我做的笔记, How to Use Git and GitHub(一) , How to Use Git and GitHub(二) 。每过一个小节一定要自己在terminal里练一下,只看不练没什么效果。我看了下自己记录的用时,整个教程用了23小时34分,21天,大概每天一个多小时吧,可以做个参考。在我看来,使用GitHub也存在如《人间词话》中的三重境界。
第一重境界:昨夜西风凋碧树。独上高楼,望尽天涯路。
作为一个小白用户,机缘巧合,你刚刚注册了GitHub的账号,还不知Git,Push,Pull,Pull Request,Repository为何物。懵懵懂懂,如一个单纯的小孩,来到了满是漂亮贝壳的沙滩,却还叫不出颜色的名字。
朋友中只有自己一个人在玩GitHub,在浏览着网页的你,心中还有淡淡的孤独与忧伤。
面对着被star过万遍的repositories,关注者以k计的id们,你发出一声长叹:什么时候我才能写出那样的名库,成为那样的牛人。
第二重境界:衣带渐宽终不悔,为伊消得人憔悴。
你创建了第一个repo,用来存放自己写过的小代码们。
你创建了 你的http://id.github.io,用hexo或jekyll开始了自己的技术博客之旅。
第一次pull request,第一次被别人pull request。
第一次创建issue,第一次被别人创建issue。
你想到了一个idea,在google search和stackoverflow的忠心辅佐下,攻克一个又一个技术难题,实现一个又一个feature,你的开源项目越来越像那么回事。
一年有365天,你的GitHub上竟然就有365条打卡记录,无一天中断。
别人在感叹,在技术上成长怎么那么难,你反问他:你见过GitHub凌晨四点的样子吗?
第三重境界:众里寻他千百度,蓦然回首,那人却在灯火阑珊处。
感谢时间这个好朋友,你有一天发现,你的followers也是以k计,你新开一个repository就引来了上百个watch。
你给Apache贡献过代码,给Tensorflow实现过feature,给Linux修过bug。
你在业界小有名气,很多人都知道你,你也认识很多人,你和你的朋友们在线上线下相遇,觥筹交错,谈笑风生。
江湖上都称呼你为大牛,在一年一度的InfoQ北京峰会上,凤凰科技一个带黑框眼镜的长发美女记者问你,“在成长为大牛的道路上,你最感谢谁?” 眼前的这个妹妹好像在哪里见过,你用拇指和食指摸了摸下巴,看着她的眼睛,缓缓说道,“感谢爸妈,感谢GitHub。”
As far as I can see, GitHub users are also experiencing the three levels described in “Poetic Remarks in the Human World” by Wang Kuo-wei.
Level 1: Last night the west wind shriveled the green-clad trees. Alone I climb the high tower, to gaze my fill along the road to the horizon.
As a new user, by any chance, you registered a GitHub account. You dont know what Git, Push, Pull, Pull Request and Repository are. Just like an innocent child, you run into a beach full of colorful shells, but you cant even name the colors.
You are the only one among your friends to play with GitHub. Surfing around the webpages, you feel a little bit lonely and sad.
Facing repositories stared in 5-digit figure and IDs followed by some k, you sighed, “When can I create a famous repo like that? When can I grow to be a top coder like him.”
Level 2: My clothes grow daily more loose, yet care I not. For you am I thus wasting away in sorrow and pain.
You created your first repo to store your old naive code.
You created http://your_id.github.io and launched your technical blogging journey by hexo orjekyll.
Your first pull request, later your first incoming pull request.
Your first issue, later your first incoming issue.
You came up with an awesome idea, and thanks to Google Search and StackOverflow, you tackled one and another challenge, implemented one and another feature, and your open source project looks just like something.
There are 365 days in a year, and we found exactly 365 contribution tiles in your GitHub profile.
Others are complaining, “How can it be so hard to grow in tech?” You replied back, “Have you ever seen what is it like in GibHub on 4am?”
Level 3: I sought her in the crowd a hundred, a thousand times. Suddenly with a turn of the head, I saw her. That one there where the lamplight was fading.
Thank to Time, my good friend. One day, you found that your followers are some k, your new repository get 100+ watches on day one.
You once contributed code for Apache, you once implemented new features for TensorFlow, you once fixed bugs for Linux.
You gained some fame in Silicon Valley. Many people know you, you also know some of them. You and your friends meet online and offline, you drink and cheers, you talk and laugh.
In the annual QCon San Francisco Summit, you were interviewed by a blonde journalist, “Along your growing path, to whom do you want to say the biggest thanks?” The babe looks familiar, but you can’t remember. Thought for a short while, you said slowly, “Thanks my parents, thanks GitHub”.
如果你想了解更多我和GitHub的故事,请阅读:
我的新博文 《GitHub Pull Request初体验 | 给Hexo博客留言页面添加评论系统》
我的博客 宋哲的国际博客
阳志平:”正是Github,让社会化编程成为现实。本文尝试谈谈GitHub的文化、技巧与影响。” 在阳志平:如何高效利用GitHub文中介 绍了Github的方方面面,包括一些很有意思的创意,如用Github做PPT,发布婚宴的邀请函等, 可以让人快速拥抱Github,十分不错。
好吧,我相信看到这里你已经晕了,这也是我一开始看那些所谓经典教程的感受。写这些教程的人都是几年以上的程序员呀,他们往往直接就告诉你所有命令的含义或者整个体系。Git 是由 Linux 之父 Linus Tovalds 为了更好地管理linux内核开发而创立的分布式版本控制/软件配置管理软件。
专家盲点(expert blind spot)就是对一个事物知道的越多,就越发不记得“不知道这个事”的情形。
所以不是程序猿可以用这个来做什么呢?Do whatever you want.
一个有自己域名的独立博客,是不是很帅?!
GitHub本身提供免费的托管服务,又提供了贴心的 Pages 功能,可以绑定你自己的域名,免费、高效、不限流量,做一个个人页面绰绰有余。
Jekyll 的教程和我自己的博客会稍后放出。。(先给自己挖个坑)
6、用GitHub协作翻译
苹果官方发布的各种官方手册,比如最近开源的 Swift numbbbbb/the-swift-programming-language-in-chinese · GitHub 就是国内一个自发组织起来的团队,30多个人用9天时间即将翻译和校对工作全部完成,他们每人都还有自己的事情,上班、上线、创业,这么大的工作量在以往简直是不可能完成的任务!
7、项目管理
GitHub最初是为了开发的管理而生,当然也就具备了项目管理的潜质,特别是与开发密切联系的项目中,它的优势尽显。比如这篇文章介绍了如何使用GitHub结合 Trello 等其它工具进行项目管理:使用GitHub进行团队合作。当然,GitHub还是很偏重开发的管理,一般的项目管理还是适合使用 wortile 之类的产品。
GitHub上的代码无法造假,也容易通过你关注的项目来了解你的知识面的宽度与深度。现在越来越多知名公司活跃在GitHub,发布开源库并招募各类人才,例如:Facebook、Twitter、Yahoo ...
开始有了第三方网站提供基于GitHub的人才招聘服务,例如:
3、在线交互学习 github 的网站Learn Git Branching 这个也很好玩~
4、[GitHub自身的官方博客](The GitHub Blog · GitHub)
5、 git-flow 备忘清单鉴于网上目前的教材都太落后,github for windows已经更新了多个版本,好多界面都发生了变化,所以来写这个教程。目的是为了帮助和我一样初学github,但是苦于找不到教程的同学,为了写最详细的教程。配备了大量的图文介绍。该教程是基于GitHub for windows (3.0.17.0)
说到什么事github,我们先看wikipedia的描述“GitHub是一个利用Git进行版本控制、专门用于存放软件代码与内容的共享虚拟主机服务。它由GitHub公司(曾称Logical Awesome)的开发者Chris Wanstrath、PJ Hyett和Tom Preston-Werner使用Ruby on Rails编写而成。”
准备工作准备工作都完了,我们开始正式学习。^_^
创建第一个代码库github for windows的界面非常清爽,的确符合geek的性质,个人表示非常喜欢。 我们来建立第一个仓库,点击左上角的+号,初次建立他会有一圈圈的涟漪,非常漂亮哦。 打开之后有三个选项,Add,Create,Clone。 我们分别来介绍一下这三个功能。
如果本地有工程,就可以使用Add添加
这个功能其实最好理解了,克隆这名字通俗易懂好理解。 如何使用Clone功能呢? 就是将在浏览器上已经创建好的项目导入到本地,换句话说就是下载到本地。
创建一个代码库, Name填写你的仓库名字。Local path写你将要保存在本地路径。
我们主要从这个功能开始github之旅。 我们在这里填写First,来创建第一个我们自己的repoeitory。
我们来找到刚刚创建的代码库在本地的位置。就是刚刚在local path的地址路径,当然如果你忘了,请右键点击First。
此时的github就会变成这个样子(Changs):
你会发现此时github会出现刚刚编辑的内容。
我们这里只选择第一个修改对象,也就是这个是测试文本就行修改。summer我们填写为第一次修改,Description我们填写为增加了这个是测试文本的内容,之后点击Commit to master。
切换到History目录下 我们会发现他改变了。 这次我们把你好进行添加。
在History目录下发生了这样的改变。会在History目录下形成一天时间线,来指出每一次的修改标题和内容,同时会把修改的内容用绿色标识标出。 我们打开本地的文本,删除刚刚添加的第一行这个是测试文本。
此时你就会发现github发生了变化。 此时的红色标识标识删除。我们写好Summer和Description并点击Commit to master。 这样我们就删除了第一行。同时在History目录下又多了一条时间轴。
这样我们就完成了删除。
上传与同步此时,当我们打开github网页,就会发现此时你的修改的内容并没有出现在这里。这是因为你没有进行同步,仅仅是在本地就行了修改。此时我们仅仅需要点击右上角的publish
此时你就会本地内容已经上传到网页上。
当你的代码库上传后就会发现,原来的publish以及变为了Sync。 点击Sync同步代码库!
我们创建第一个分支取名为new masterh,点击Create new branch创建第一个分支。
我们发现此时的分支已经切换到了我们刚刚创建的分支new masterch 。
我们来修改new masterch分支上的内容。 我们仍旧打开FirstDemo.txt进行编辑。输入以下内容
创建的第一个分支。
打开github进行,填写Summary和Description
之后我们点击Commit to new-master在History目录下,我们可以看到会有两条主线,分别是master和new-master并且在new-master的分支下又一个蓝色的实线空心圈和一个虚线空心圈。
实线圈表示当前的节点,空心圈表示下一次修改时的节点。
红线标示的部分就是当前的分支
点击红色划线部分就会出现分支的列表
我们点击master就会切换到master分支。
这个操作和同步仓库是一个操作,点击Publish/Sync上传或同步分支。
删除分支首先要把分支切换到你要删除的分支下,如我们要删除new master,将分支切换到new master
点击右上角齿轮就会出现Delete new master 点击Delete new master就会弹出一个对话框,询问删除的内容。
第一个yes ,Delete both是将本地与网页全部删除;
第二个Delete local only仅仅是删除本地。
第三个是取消。
将一个分支与master分支进行合并。 我们首先把分支切换到master下,点击Update from new-branch进行分支的合并。
此时我们查看history目录下就会
GitHub Flow是一个轻量级的,基于分支的工作流程,支持团队和部署在那里的定期做项目。
在我们的队友添加一个写的权限,这样我们的队友才能很好的修改代码。 我们打开网页上的GitHub,点击settings,
之后我们找到collaborators,这里会让我们验证密码,之后就有添加合作者的选项。
这样我们就能添加我们的小伙伴了! 这样我们就添加了新的小伙伴,新的小伙伴有着同样的权限去修改和管理代码。 此时我们就会看到我的小伙伴wevan的github主页上就会出现关于我创建的First的各种通知。
在我们创建一个叫add new function的分支。
创建一个分支 Create a branch 当你工作的一个项目,你会在任何给定的时间有一堆不同的功能或正在进行的想法 - 其中一些是蓄势待发,而另一些则不是。分支的存在是为了帮助你管理这个工作流程。 When you're working on a project, you're going to have a bunch of different features or ideas in progress at any given time – some of which are ready to go, and others which are not. Branching exists to help you manage this workflow. 当您在项目中创建一个分支,你创造一个环境,在那里你可以尝试新的想法。你让一个分支的更改不会影响主分支,让你可以自由进行实验,并提交更改,在你的分支将不会被合并,直到它准备好知识安全的人所正在与合作进行审查。 When you create a branch in your project, you're creating an environment where you can try out new ideas. Changes you make on a branch don't affect the master branch, so you're free to experiment and commit changes, safe in the knowledge that your branch won't be merged until it's ready to be reviewed by someone you're collaborating with. ProTip 分支在Git中是一个核心概念,整个GitHub的流量是基于它。这里只有一个规则:在任何主分支总是部署。 Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable. 正因为如此,这是非常重要的一个功能或修复工作时,你的新分支关老爷的创建。您的分支名应该是描述(例如,重构的身份验证,用户的内容缓存键,使视网膜-化身),以便其他人可以看到正在处理。 Because of this, it's extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.来自GitHub Flow
我们首先把分支切换到新的分支上add new function
修改新的版本
填写好新的Summary和Description,提交新的版本并同步。 这样小伙伴登陆到GitHub上就看到了就可以清楚的看到一切的修改。
添加提交 Add commits 一旦你的分支已经建立,现在是时候开始进行更改。无论何时添加,编辑或删除一个文件,你作出承诺,并将其添加到您的分支。提交加入这一过程保持你的进步轨迹,你在一个特性分支工作。 Once your branch has been created, it's time to start making changes. Whenever you add, edit, or delete a file, you're making a commit, and adding them to your branch. This process of adding commits keeps track of your progress as you work on a feature branch. 还承诺创建工作的透明历史,其他人可以按照理解你做了什么,以及为什么。每次提交都有一个关联的提交信息,这是解释为什么一个特定的变化作出了说明。此外,每次提交被认为是变革的一个独立单元。这使您可以回滚的变化,如果发现错误,或者如果你决定在一个不同的方向前进。 Commits also create a transparent history of your work that others can follow to understand what you've done and why. Each commit has an associated commit message, which is a description explaining why a particular change was made. Furthermore, each commit is considered a separate unit of change. This lets you roll back changes if a bug is found, or if you decide to head in a different direction. ProTip
提交信息是重要的,特别是因为Git跟踪更改,然后将它们显示为承诺一旦他们推到服务器。通过字迹清晰提交信息,你可以更容易为其他人跟着,并提供反馈。 Commit messages are important, especially since Git tracks your changes and then displays them as commits once they're pushed to the server. By writing clear commit messages, you can make it easier for other people to follow along and provide feedback.来自GitHub Flow
这个是整个流程中比较关键的一步,发布Pull Request。
点击客户端或者网页上的Pull Request发布。 我们这里点击Pull Request
我们填写好必要的说明性文字 点击Send Pull Request 他既然让我们到GitHub上看,我们就听他的,点击,进入。
我们发现小伙伴已经在下面留言了!
你的小伙伴开始对你的代码讨论,修改,迭代。
部署讨论和审查你的代码 Discuss and review your code 一旦拉入请求已被打开,人或团队审查您的变化可能有疑问或意见。也许编码风格不匹配项目的指导方针,改变缺少单元测试,或者也许一切看起来不错,道具都是为了。引入请求旨在鼓励并捕获这种类型的对话。 Once a Pull Request has been opened, the person or team reviewing your changes may have questions or comments. Perhaps the coding style doesn't match project guidelines, the change is missing unit tests, or maybe everything looks great and props are in order. Pull Requests are designed to encourage and capture this type of conversation. 您还可以继续推送到你的分支在你提交的讨论和反馈光。如果有人评论说,你忘了做某件事,或者如果在代码中的错误,你可以在你的分支修复它,推高的变化。GitHub上会显示新的提交和其他任何意见,你可能会收到统一拉请求视图。 You can also continue to push to your branch in light of discussion and feedback about your commits. If someone comments that you forgot to do something or if there is a bug in the code, you can fix it in your branch and push up the change. GitHub will show your new commits and any additional feedback you may receive in the unified Pull Request view.
ProTip 拉请求的意见都写在降价,所以你可以插入图片和表情符,使用预先格式化的文本块,等轻质格式。 Pull Request comments are written in Markdown, so you can embed images and emoji, use pre-formatted text blocks, and other lightweight formatting.
合并部署 Deploy 一旦你拉的请求进行了审查和部门通过你的测试,您可以部署您的更改,以验证他们的生产。如果你的分支造成的问题,您可以通过部署现有的主投产回滚 Once your pull request has been reviewed and the branch passes your tests, you can deploy your changes to verify them in production. If your branch causes issues, you can roll it back by deploying the existing master into production.
合并分支我们之前已经说过,这里就不再赘述。
合并 Merge 现在,您的更改在生产中得到了验证,现在是时候你的代码合并到主分支。 Now that your changes have been verified in production, it is time to merge your code into the master branch. 合并后,引入请求保护的历史变迁到您的代码记录。因为他们是搜索的,他们不让任何人回去的时间理解为什么以及如何决定了。 Once merged, Pull Requests preserve a record of the historical changes to your code. Because they're searchable, they let anyone go back in time to understand why and how a decision was made.
ProTip 通过将某些关键字到您的拉请求的文本,你可以用代码相关联的问题。当你拉入请求合并,相关问题也将被关闭。例如,输入短语关闭#32将关闭在仓库中发行数量32。欲了解更多信息,请查看我们的帮助文章。 By incorporating certain keywords into the text of your Pull Request, you can associate issues with code. When your Pull Request is merged, the related issues are also closed. For example, entering the phrase Closes #32 would close issue number 32 in the repository. For more information, check out our help article.
在上述的几个教程里讲解了一些Github的基础使用,现在开始讲解一些使用技巧。
在github页面上是没有搜索的按钮,如何搜索呢。 在网页上按T就会出现。 这样我们就能很方便的查找到我们需要的代码了。
常常在版本描述或者pull request时我们需要对伙伴的代码进行一下评论与说明,光是文字有点很死板,其实github给我有emoji,如何使用呢?其实很简单,只需要冒号就可以 :
这样我们就可以看到emoji表情,当然默认会显示五个常用的,你也可以继续敲下emoji的名字,出现更多(这里有所有的表情)。
有些在github中的文件我们是不想上传的,我们如何过滤掉它们呢? 在github中对不想上传的文件点击右键。就会出现下面选项。 Ignore file忽略这个文件 Ignore all.txt files 忽略所有的以.txt结尾的文件 这样就可以过滤掉你不想上传的文件
如何高效的搜索一个你想要的库呢? 我们常常评判一个项目的标准有star数目,fork数目和跟新时间。 通过搜索命令
stars
stars:>1000
表示star数目大于1000。
fork
fork:>1000
表示fork数目大于1000。
语言搜索
java,html等等
综合一下就是,比如你要查找一个stars大于1000的,fork大于200的java代码。
stars:>1000 fork:>200 java
就是这样。
码字不易,终于写完了,如果觉得对你有帮助,我的目的就达到了。
谢谢
如有错误,还望指正。
不要光收藏,点个赞啊!
转载请通知作者!
谢谢!!!!!!!!!!!!!!!!!!!!
放(打)一(广)个(告)比较有意思的《GitHub - phodal/github-roam: GitHub 漫游指南》电子书,当然也是放在GitHub上的。
漫游在第547天里:phodal (Fengda Huang) · GitHub
为什么没人说Command Line???
新手都觉得command line太难,其实不然,就那么几个需要用的命令,多用几次就记熟了。记熟了不但操作极为方便,也是装X利器啊!!
跑题了。先说GitHub
请大家假设以下的情景,现在有一个项目,要有两个人来完成,小明和小红。
小明和小红一人一台电脑,分别在两个屋子里工作。
首先在GitHub上有一个原档,小明小红分别下载到自己的电脑里开始工作。
假设原文档如下str = "Hello Zhihu!"
for letter in str:
print (letter)
这时候小明说,好,我来接着写
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
小红拿到文件之后也说,好,我来接着写。
str = "Hello Zhihu!"
for letter in str:
print (letter)
str1="LiMaBianWangHong"
这个时候小明和小红是互相不知道对方在干什么的。
但是两个人必须同时完成这个coding,这个时候该怎么办呢?
没错,在GitHub上同步两人的文件。
小明先从GitHub上下载。小明一看没变化(此时小红还没上传),于是把自己的改变传上去。
此时原文档变成了name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="LiMaBianWangHong"
小红确认了code无误之后又把自己的code同步到Github上
这时小明再同步,他就会看到name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="LiMaBianWangHong"
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="ChouNv"
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="XiaoHongShiNvShen"
这时小明先上传了上去,小红一同步一看
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
<<<<<<<<<Head
Here is the original change.
str1="XiaoHongShiNvShen"
=======
Here is the modified change.
str1="ChouNv"
这个时候怎么办呢,就要手动修改。把提示的line全都删掉即可。
name = "XiaoMing"
str = "Hello {}! {}Zui Niu Bi ".format(name, name)
for letter in str:
print (letter)
str1="XiaoHongShiNvShen"
print("xiao ming shi sb")
讲到这里大家应该就对github有一个大致的印象了。基本就是个同步工作进程的工具。
那么实现同步都需要哪些命令行呢?其实很简单。我保证你一分钟就能记住。
小明或者小红得先看看github上有没有其他人的更新,所以他要先输入
>>> git status
这个很好理解吧,就是查看状态。
如果这时候先是说有修改过的文件,那你就要下载下来对不对啊。>>> git pull
是不是很简单,往下拉
你拉下来之后,核对了,无误,要把自己的成果发布上去,怎么弄呢?
你想象两座山之间,要传递食物,中间有个小滑索的车,你是不是先把食物放进小车里,之后把小车推到对面的山去呢?
这里也是一样的,你要先>>> git add
>>> git add xiaoming.txt
现在食物放进车里了,下一步呢?
对面的山里人可能不知道你这吃的是什么,你是不是得写个条子留个言告诉别人是什么食物啊?
>>> git commit -m "这是汉堡包"
commit不难理解吧, -m就是message的意思。是什么message呢? “这是汉堡包”
一般这里写你对文件做出了什么修改 比如
>>> git commit -m "new feature: xiao hong bian bai fu mei"
至此你应经做完全部准备工作,就差推出去了!
>>> git push origin master
push很好理解吧,origin master 代表你的权限。多用几次就熟悉了!
以后不用开网页,用terminal上传文件到github,逼格高高的!
你们如果以为我只会秀恩爱那就错了,应读者要求,最近在写一个针对小白的从0开始学习GitHub的系列,无门槛,包教包会,感兴趣的不妨看一下:
从0开始学习 GitHub 系列之「初识 GitHub」 - AndroidDeveloper - 知乎专栏
从0开始学习 GitHub 系列之「加入 GitHub」 - AndroidDeveloper - 知乎专栏
待续...
++++++++++++++++++++++++++++++++++++++++++++++++++++
我对GitHub可是真爱粉,媳妇也是写程序的,也知道GitHub,今天我发给媳妇一个链接,说你看我GitHub粉丝都涨到多少啦,媳妇一脸不屑的打开我的GitHub,然后就感动的哭了。。。
不推荐看纸质资料,git和github涉及到很强的操作性,只看资料里的讲解是完全不够的。而且就像任何一门科学一样,我们为什么要用git,git有什么好处,学会了git后如何在github上和别人collaborate,这些东西都最好有人直接告诉我们。只告诉你怎么做不告诉你为什么以及背后原理的都是在耍流氓。千万别以为学会了git就会用github,除非你只玩单机版。不fork别人的repo,也不pull request,这样还怎么愉快地同性交友?
我之前只看了廖雪峰的那个git教程,因为网上很多人推荐。但看完了对git还是一知半解,github也只会个push……之后自己用pelican做博客想放在github上,结果还是因为不懂原理结果在创建.io repo的时候把pelican的原文件都覆盖了,还不知道怎么退回到原来的版本……唉,年少无知啊。直到一个月前发现了Udacity出的这门课How to Use Git and GitHub,https://www.udacity.com/course/how-to-use-git-and-github--ud775.
这门课前两个lesson都在讲git的各种技巧,背后的概念也解释得很清楚。有了良好的git基础后lesson 3讲授如何使用github。介绍了很多在实际开发过程中遇到的问题,最典型的就是merge conflict,比如你fork了一个original repo,你在本地对local repo里little_prince.txt做了修改,push到了fork repo,但是此时original repo里的同一文件也被人做了修改。所以当你想要把自己的branch merge到 original repo的时候会有merge conflict。这种问题在collaborate过程中很常见,如何解决这种问题lesson 3里也讲得很清楚,先画概念图告诉你大致原理,然后用命令行演示给你看,非常良心。
不过只有英文字幕,如果觉得有困难的话,可以参考我做的笔记, How to Use Git and GitHub(一) , How to Use Git and GitHub(二) 。每过一个小节一定要自己在terminal里练一下,只看不练没什么效果。我看了下自己记录的用时,整个教程用了23小时34分,21天,大概每天一个多小时吧,可以做个参考。在我看来,使用GitHub也存在如《人间词话》中的三重境界。
第一重境界:昨夜西风凋碧树。独上高楼,望尽天涯路。
作为一个小白用户,机缘巧合,你刚刚注册了GitHub的账号,还不知Git,Push,Pull,Pull Request,Repository为何物。懵懵懂懂,如一个单纯的小孩,来到了满是漂亮贝壳的沙滩,却还叫不出颜色的名字。
朋友中只有自己一个人在玩GitHub,在浏览着网页的你,心中还有淡淡的孤独与忧伤。
面对着被star过万遍的repositories,关注者以k计的id们,你发出一声长叹:什么时候我才能写出那样的名库,成为那样的牛人。
第二重境界:衣带渐宽终不悔,为伊消得人憔悴。
你创建了第一个repo,用来存放自己写过的小代码们。
你创建了 你的http://id.github.io,用hexo或jekyll开始了自己的技术博客之旅。
第一次pull request,第一次被别人pull request。
第一次创建issue,第一次被别人创建issue。
你想到了一个idea,在google search和stackoverflow的忠心辅佐下,攻克一个又一个技术难题,实现一个又一个feature,你的开源项目越来越像那么回事。
一年有365天,你的GitHub上竟然就有365条打卡记录,无一天中断。
别人在感叹,在技术上成长怎么那么难,你反问他:你见过GitHub凌晨四点的样子吗?
第三重境界:众里寻他千百度,蓦然回首,那人却在灯火阑珊处。
感谢时间这个好朋友,你有一天发现,你的followers也是以k计,你新开一个repository就引来了上百个watch。
你给Apache贡献过代码,给Tensorflow实现过feature,给Linux修过bug。
你在业界小有名气,很多人都知道你,你也认识很多人,你和你的朋友们在线上线下相遇,觥筹交错,谈笑风生。
江湖上都称呼你为大牛,在一年一度的InfoQ北京峰会上,凤凰科技一个带黑框眼镜的长发美女记者问你,“在成长为大牛的道路上,你最感谢谁?” 眼前的这个妹妹好像在哪里见过,你用拇指和食指摸了摸下巴,看着她的眼睛,缓缓说道,“感谢爸妈,感谢GitHub。”
As far as I can see, GitHub users are also experiencing the three levels described in “Poetic Remarks in the Human World” by Wang Kuo-wei.
Level 1: Last night the west wind shriveled the green-clad trees. Alone I climb the high tower, to gaze my fill along the road to the horizon.
As a new user, by any chance, you registered a GitHub account. You dont know what Git, Push, Pull, Pull Request and Repository are. Just like an innocent child, you run into a beach full of colorful shells, but you cant even name the colors.
You are the only one among your friends to play with GitHub. Surfing around the webpages, you feel a little bit lonely and sad.
Facing repositories stared in 5-digit figure and IDs followed by some k, you sighed, “When can I create a famous repo like that? When can I grow to be a top coder like him.”
Level 2: My clothes grow daily more loose, yet care I not. For you am I thus wasting away in sorrow and pain.
You created your first repo to store your old naive code.
You created http://your_id.github.io and launched your technical blogging journey by hexo orjekyll.
Your first pull request, later your first incoming pull request.
Your first issue, later your first incoming issue.
You came up with an awesome idea, and thanks to Google Search and StackOverflow, you tackled one and another challenge, implemented one and another feature, and your open source project looks just like something.
There are 365 days in a year, and we found exactly 365 contribution tiles in your GitHub profile.
Others are complaining, “How can it be so hard to grow in tech?” You replied back, “Have you ever seen what is it like in GibHub on 4am?”
Level 3: I sought her in the crowd a hundred, a thousand times. Suddenly with a turn of the head, I saw her. That one there where the lamplight was fading.
Thank to Time, my good friend. One day, you found that your followers are some k, your new repository get 100+ watches on day one.
You once contributed code for Apache, you once implemented new features for TensorFlow, you once fixed bugs for Linux.
You gained some fame in Silicon Valley. Many people know you, you also know some of them. You and your friends meet online and offline, you drink and cheers, you talk and laugh.
In the annual QCon San Francisco Summit, you were interviewed by a blonde journalist, “Along your growing path, to whom do you want to say the biggest thanks?” The babe looks familiar, but you can’t remember. Thought for a short while, you said slowly, “Thanks my parents, thanks GitHub”.
如果你想了解更多我和GitHub的故事,请阅读:
我的新博文 《GitHub Pull Request初体验 | 给Hexo博客留言页面添加评论系统》
我的博客 宋哲的国际博客
阳志平:”正是Github,让社会化编程成为现实。本文尝试谈谈GitHub的文化、技巧与影响。” 在阳志平:如何高效利用GitHub文中介 绍了Github的方方面面,包括一些很有意思的创意,如用Github做PPT,发布婚宴的邀请函等, 可以让人快速拥抱Github,十分不错。