GitHub入门

代码管理方式——集中与分散

集中型

以 Subversion 为表明的集中型,所示将仓库集中存放在服务器之中,因此只存在一个仓库。这就是为何这种版本管理系统会被称做集中型。git

集中型将全部数据集中存放在服务器当中,有便于管理的优势。可是一旦开发者所处的环境不能链接服务器,就没法获取最新的源代码,开发也就几乎没法进行。服务器宕机时也是一样的道理,并且万一服务器故障致使数据消失,恐怕开发者就再也见不到最新的源代码了。程序员

分散型

GitHub 将仓库 Fork 给了每个用户。Fork 就是将 GitHub 的某个特定仓库复制到本身的帐户下。Fork 出的仓库与原仓库是两个不一样的仓库,开发者能够随意编辑。github

分散型拥有多个仓库,相对而言稍显复杂。不过,因为本地的开发环境中就有仓库,因此开发者没必要链接远程仓库就能够进行开发。web

GitHub相关

快捷键

在 GitHub 中,不少页面均可以使用键盘快捷键。在各个页面按下 shift + / 均可以打开键盘快捷键一览表,查看当前页面的快捷键。面试

Explore

从各个角度介绍 GitHub 上的热门软件。浏览器

  • GitHub 公司特别介绍的软件(附开发者制做的视频)服务器

  • 按语言筛选本日 / 周 / 月的热门仓库 / 开发者markdown

Gist

Gist 功能主要用于管理及发布一些不必保存在仓库中的代码,好比小的代码片断等。系统会自动管理更新历史,而且提供了 Fork 功能。在 Gist 上添加的代码示例能够嵌入博客中。固然,若是选择了语言,还会自动添加语法高亮。ssh

Blog

这是到 GitHub 公司官方博客的超连接,GitHub 公司会在上面发布通知。新功能的通知、新入职员工的介绍、drinkup 聚会的信息等都会在上面按期发布。编辑器

github上的交流:

GitHub 中可以使用的描述方法并不止“@ 用户名”一种。

输入“@ 组织名”可让属于该 Organization(组织)的全部成员收到通知 7。输入“@ 团队名”可让该团队的全部成员收到通知。这就是同时向多人发送通知的方法。

输入“# 编号”,会链接到该仓库所对应的 Issue 编号。输入“用户名 / 仓库名 # 编号”则能够链接到指定仓库所对应的 Issue 编号。只要按照这类特定格式书写便会自动建立连接。

只要将感兴趣的仓库添加至 Watch 中,就能够在 News Feed 查 看该仓库的相关信息。

News Feed

显示当前已 Follow 的用户和已 Watch 的项目的活动信息,用户能够在这里查看最新动向。将右上角 RSS 标志的 URL 添加到 RSS 阅读器中,还能够经过 RSS 查看。

Issues

在这里能够查看用户拥有权限的仓库或分配给本身的 Issue。当用户同时进行多个项目时,能够在这里一并查看 Issue。

Broadcast

主要用于接收 GitHub 公司发来的通知或使用技巧的小贴士。

Your Repositories

按更新时间顺序显示用户的仓库。标有钥匙图案的是非公开仓库,标有相似字母 Y 图案的是用户 Fork 过的仓库。

Public contributions

一格表示一天,记录当日用户对拥有读取权限的仓库的大体贡献度。贡献度的衡量标准包括发送 Pull Request 的次数、写 Issue 的次数、进行提交的次数等。颜色越深表明贡献度越高。

Public Activity

从这里能够了解到该用户日常都在 GitHub 上作些什么。好比查看一下崇拜已久的程序员的公开活动,就能够知道他如今关注些什么,或者正在热心于开发些什么。

Pull Requests

在 Pull Requests 中能够列表查看并管理 Pull Request。代码的更改和讨论均可以在这里进行。旁边显示的数字表示还没有 Close 的 Pull Request的数量。

Pulse

显示该仓库最近的活动信息。该仓库中的软件是无人问津,仍是在火热地开发之中,从这里能够一目了然。

Graphs

以图表形式显示该仓库的各项指标。让用户轻松了解该仓库的活动倾向。

Clone in Desktop

启动 GitHub 专用的客户端应用程序并进行 clone。

releases

显示仓库的标签(Tag)列表。同时能够将标签加入时的文件以归档形式(ZIP、tar.gz)下载到本地。软件在版本升级时通常都会打标签,若是须要特定版本的文件,能够从这里寻找。

Compare & review

能够查看当前显示的分支与其余分支的差异,以便进行审查。点击这个按钮,会出现一个页面让用户选择比较对象。

行连接

文件内容的左侧会显示该文件的行号。假如咱们点击第 10 行的行号,这一行就会被高亮标记为黄色,同时 URL 末尾会自动添加“#L10”。使用这个 URL,程序员们在交流时,就能够将讨论明确指向某一行。另外,若是将“#L10”改为“#L10-15”,则会标记该文件的第10~15 行。

在仓库页面试着按下键盘的 t 键,而后输入要找的目录或文件的部分名称。筛选器会在仓库的目录和文件中进行筛选,搜索出您要找的文件。

URL使用技巧

这样,就能够查看两个分支间的差异。

查看 master 分支在最近 7 天内的差异,支持day,week,month,year。若是差异过大则不会列出全部提交,只显示最近的一部分。

查看 master 分支 2013 年 1 月 1 日与如今的区别。可是若是指定日期与如今的差异过大,或者指定日期过于久远,则没法显示。

Issue

用于 BUG 报告、功能添加、方向性讨论等,将这些以 Issue 形式进行管理。Pull Request 时也会建立 Issue。旁边显示的数字是当前处于Open 状态的 Issue 数。

在软件开发过程当中,开发者们为了跟踪 BUG 及进行软件相关讨论,进而方便管理,建立了 Issue。管理 Issue 的系统称为 BTS(Bug Tracking System,BUG 跟踪系统)。当今具备表明性的 BTS 有 Redmine,Trac,Bugzilla等。GitHub 也为自身加入了 BTS 的功能。

  • 支持markdown语法

  • 支持指定语法时代码高亮

  • 支持拖拽添加图片

  • 支持添加标签整理 Issue

  • 支持添加里程碑来管理 Issue(相似于进度条的一个东西)

CONTRIBUTING.md

在描述 Issue 时,经常会看到贡献规范的连接。

在该仓库的根目录下添加 CONTRIBUTING.md 文件后该连接就
会显示出来。规范的内容通常包括报告时Issue的描述方法、Pull Request 时的规则或要求、许可证的相关信息等。为了在开源项目开发中能与其余人和谐相处,请务必在贡献以前仔细阅读这些规范。

Tasklist语法

使用 GFM 的一项独有功能,那就是 Tasklist 语法。

# 本月要作的任务
- [ ] 完成图片
- [x] 完成部署工具的设置
- [ ] 实现抽签功能

提交与Issue的交互

在 Issue 一览表中咱们能够看到,每个 Issue 标题的下面都分配了诸如“#24”的编号。只要在提交信息的描述中加入“#24”,就能在 Issue 中显示该提交的相关信息,使关联的提交一目了然。这里只需轻轻点击一下即可以显示相应提交的具体内容,在代码审查时省去了从大量提交日志中搜索相应提交的麻烦,很是方便。

若是一个处于 Open 状态的 Issue 已经处理完毕,只要在该提交中如下列任意一种格式描述提交信息,对应的 Issue 就会被 Close。

  • fix #24

  • fixes #24

  • fixed #24

  • close #24

  • closes #24

  • closed #24

  • resolve #24

  • resolves #24

  • resolved #24

Issue与Pull Request

在 GitHub 上,若是给 Issue 添加源代码,它就会变成咱们立刻要讲到的 Pull Request。Issue 与 Pull Request 的编号相互通用,经过 GitHub的 API 能够将特定的 Issue 转换为 Pull Request,可以完成这一操做的是 hub 命令。

Pull Requests

显示用户已进行过的 Pull Request。经过这里,开发者能够很方便地追踪 Pull Request 的后续状况。

Pull Request 是用户修改代码后向对方仓库发送采纳请求的功能。在列表中点击特定的 Pull Request 就会进入详细页面。页面上方显示着此次是从谁的哪一个分支向谁的哪一个分支发送了 Pull Request。

连接妙用

假设 Pull…Request 的 URL 以下所示。

https://github.com/用户名/仓库名/pull/28

若是想获取 diff 格式的文件,只要像下面这样在 URL 末尾
添加 .diff 便可。

https://github.com/用户名/仓库名/pull/28.diff

同 理, 想 要 patch 格 式 的 文 件, 只 需 要 在 URL 末 尾 添加 .patch 便可。
   

https://github.com/用户名/仓库名/pull/28.patch

Conversation

能够查看与当前 Pull Request 相关的全部评论以及提交的历史记录。提交日志的右侧有该提交的哈希值,点击连接便可确认相应提交的详细信息。

可使用R键快速引用选中的评论。

Commits

在 Commits 标签页中,按时间顺序列表显示了与当前 Pull Request相关的提交。标签上的数字为提交的次数。每一个提交右侧的哈希值能够链接到该提交的代码。

在评论中输入“:”(冒号)便会启动表情自动补全功能。只要输入几个与该表情相关的字母,系统就会为您筛选自动补全的对象。选择想要的表情,其相应代码(先后都有冒号的字符串)便会插入到文本框中。

(请登陆 http://www.emoji - cheat - sheet.com/ 查找可以使用的表情)

Files Changed

Files Changed 标签页中能够查看当前 Pull Request 更改的文件内容以及先后差异。标签上的数字表示新建及被更改的文件数。默认状况下系统会将空格的不一样也高亮显示,因此在空格有改动的状况下会难以阅读。这时只要在 URL 的末尾添加“?w=1”就能够不显示空格的差异。将鼠标指针放到被更改行行号的左侧,咱们会看到一个加号。点击这个加号能够在代码中插入评论。这样,评论是针对哪行代码的就一目了然了。

Wiki

Wiki 是一种比 HTML 语法更简单的页面描述功能。经常使用于记录开发者之间应该共享的信息或软件文档。数字表示当前 Wiki 的页面数量。全部
有权限的人均可以对文章进行修改,因此比较适合多人共同编写文章的状况。建立、编辑文档时没必要另外启动软件,用起来十分方便,很是适合用来针对更新频率较高的软件进行文档等信息方面的汇总。通常状况下,Wiki 中记载着软件相关的 FAQ、文档、代码示例及解说等信息。

  • 支持GFM。

  • Wiki 功能自己的数据也在 Git 中进行管理。

    • 用户可以经过 clone操做获取 Wiki 仓库,而后在本地建立、编辑页面,进行提交再 push,即可以完成对 Wiki 的建立及编辑工做。

  • 在 Pages 标签页中能够列表查看 Wiki 页面。

  • 在 History 标签页中能够查看 Wiki 的修改历史记录。

  • 全部 Wiki 页面均可以显示侧边栏。

    • 作法很简单,只要建立名为“_sidebar”的页面便可。_sidebar 页不会显示在 Pages 的页面一览中。在编辑各页面时页面下部会附加 Sidebar 段,用户能够在这里编辑侧边栏的内容。

Graphs

在 Graphs 页中,能够经过 4 种图表查看该仓库的相关统计信息。

Code Frequency

Code Frequency 中显示了该仓库中代码行数的增长量和删除量。一款优秀的软件并不会一味地增长代码,在通过重构以后,代码量每每会下降。

Punchcard

从 Punchcard 的图中咱们能够直观地掌握一周内天天什么时候收到的提交最多。黑色圆越大,表示提交越频繁。仓库的关键人物每每会出如今提交频率高的时间段,所以用户发送的 Pull Request 最有可能在这段时间内被处理。大体了解时间规律,将有助于各位把握好发送 Pull Request 以及等待回复的时间点。另外,该软件的开发是集中在早上仍是晚上,从这张图中也可一目了然。

Network

以图表形式显示包括克隆仓库在内的全部分支的提交。从图上能够直观地看出每一个人作了多少工做。将鼠标指针停留在表中提交或合并的点上,能够查看相应的参考内容。

Settings

关于仓库的设置。

GitHub Pages

GitHub 有一个名为 GitHub Pages 的仓库,用户能够利用该仓库中的资料建立 Web 页,用来发布仓库中软件的相关信息。若是已经建立过GitHub Pages,则会显示相应 URL。点击 Automatic Page Generator 便可以自动建立 GitHub Pages。

Collaborators

用户主要在这里设置仓库的访问权限。若是仓库隶属于我的帐户,那么能够添加 GitHub 的用户名,赋予该用户直接读写仓库的权限。不过,若是仓库隶属于 Organization 帐户,则须要像所示的那样先建立 Team,而后赋予该 Team 读写仓库的权限。像这样使用 Organization 帐户能够高效地设置仓库权限,在公司等多人共同进行开发的组织中,建议使用 Organization 帐户。

Webhooks & Services

在这个页面中,用户能够添加 Hook 让 GitHub 仓库与其余服务集成。经过 Add webhook 能够添加用户本身的 webhook。经过 Configureservices 则能够从 GitHub 事先列出的能够集成的服务中进行选择。能与GitHub 集成的服务很是多,其中还包括邮件及 IRC 等社交服务。

Deploy Keys

在这个页面中,用户能够添加用于部署的公开密钥,容许以只读方式访问仓库。设置公开密钥后,用户可使用私有密钥经过 ssh 协议 clone 仓库。要注意的是,这里添加的公开密钥·私有密钥对没法再添加到其余仓库。使用 Deploy Keys 功能时,须要给每一个仓库赋予不一样的密钥对。

Notifications

每当建立 Issue、收到评论、建立 Pull Request 等状况发生时,咱们就会在 Notifications 中收到通知。

其余功能

GitHub Pages

GitHub Pages 主要用于在 GitHub 上托管静态 HTML,以便发布项目的 Web 页。能够绑定独立域名。常被使用为静态博客。

GitHub Enterprise

GitHub Enterprise 专为那些没法将源代码放到公司以外的企业设计。这项服务能够以虚拟机的形式提供 GitHub。

GitHub API

GitHub 面向开发者公开了 API。

Gist

Gist 是一款简单的 Web 应用程序,常被开发者们用来共享示例代码和错误信息。它使用JavaScript 编写的 Ace 编辑器,只需打开浏览器即可编写简单代码。另外,Gist 中的文档都在版本管理系统的管理之下,用户能够放心编辑。并且因为其版本历史记录保管在 Git 仓库中,因此还能够经过clone 操做将 Gist 获取至本地。共享 Gist 的人之间可以互相添加评论,全部交流都会被记录下来。Gist 支持多种语言的语法高亮,能够大幅加强代码可读性。能够说,这一工具就是专为程序员设计的。