高手都是怎么玩GitHub的？

前段时间一个杭州买房经验分享在GitHub上火了，迅速成为GitHub上的网红并且一度跃居到榜首位置。在别人把GitHub玩儿的那么浪的同时你还认为GitHub只是一个代码分享网站？近期，David Gilbertson上发表了这篇文章，收获了近一万五千个赞。快来学会这12招，你也能像高手一样玩转GitHub。

原文在这里：

https://hackernoon.com/12-cool-things-you-can-do-with-github-f3e0424cf2f0

招数一：在 github.com 上编辑代码

当你使用GitHub，查看一些文件（任何的文本文件或者仓库），能看到右上方有一个小铅笔图标。点击后就可以编辑文档。完成后，按照提示点击Propose file change，GitHub就会为你fork这个仓库并创建一个 pull request，这样GitHub就为你创建了一个分支。

这对于改一些排版错误或者防恶意篡改是很有帮助的。

招数二：粘贴图像

在问题和评论中，不必局限于文字，你还可以直接粘贴图片，当你粘贴时，图片会被上传至云端，并以markdown的形式显示。

招数三：格式化代码

如果你想写一个代码块，你可以在开始处写三个反引号，然后GitHub会识别你在用什么语言，并对你的代码进行高亮处理。

如果你发布如Vue、Typescript、JSX这样的语言，你也可以明确告诉GitHub你想用那种高亮方式来显示。

如下图中，第一行使用```jsx打头，就是明确告诉GitHub，我用的是JSX：

显示效果如下：

这可以扩展到gist（GitHub 推出的基于Git 的代码片段管理服务）。如果你给gist一个.jsx的扩展名，那么你会得到JSX的高亮，Github支持高亮显示的语言列表：

https://github.com/github/linguist/blob/fc1404985abb95d5bc33a0eba518724f1c3c252e/vendor/README.md

招数四：使用魔术词(magic words)在PR中关闭问题

比如你在创建一个pull request去修复issue #234。那你可在 PR 的描述或者随意一个评论中输入“fixes #234”，就可以自动合并PR并关闭这个问题，是不是很酷炫。

（提交信息里可以使用fix/fixes/fixed, close/closes/closed或者resolve/resolves/resolved等关键词，更多请查看：

https://help.github.com/articles/closing-issues-using-keywords）

招数五：链接评论

你是否曾想链接到一个特定的评论，但却不知道如何操作？其实超级简单，只需要点击名字旁边的日期/时间就可以了。

招数六：链接到代码

既然能链接到评论，那你一定会问能不能链接到代码上？答案是可以的。

试试看这个操作：在查看代码文件时，点击代码边上的行号。

你看到了么？浏览器顶部的URL随之更新为行号。如果你按住 Shift 并单击另一个行号，URL会再次更新，并且高亮这两个行号之间的所有代码段。

你现在可以分享这个URL了，但这个URL只会指向当前分支，如果文件中分享的内容修改后，怎么办呢？也很简单，只需要分享它的永久链接(permalink)。

招数七：像使用命令行一样使用GitHub URL

使用UI浏览GitHub很好用，不过有时候最快的方式是使用URL来浏览。比方说，如果我想跳转到正在处理的分支上，并想它查看主分支的差异，我可以在我的仓库名后面输入/compare/branch-name（分支名称）。

如下图，可以查看主分支和当前分支的区别：

如下图所示，如果我想要处理integration分支，我只要输入/compare/integration-branch…my-branch，就能看到与主分支的区别了。

这一步你可以配合键盘快捷键Ctrl + L或者cmd + L，就可以让光标直接移动到URL中（最起码chrome是这样的）。加上浏览器的自动完成功能，这些快捷键一起使用让分支之间跳转变得非常简单和方便。

友情提示：用箭头键来移动chrome的自动完成功能，使用Shift+Delete来删除某一条历史记录（比如合并了分支之后）。

(不知道我在文章里面用“shift + delete”这种方式表达读者能够理解，虽然“+”并不是真的需要在使用的时候按下的键，但是我觉得这样的写法比较让我觉得看起来舒服。)

招数八：在问题中创建列表

你想像下图那样，在你的问题中看到复选框列表么？

当你查看问题时，你想不想让它变成“2 of 5”这样的展现形式。

如果想，你可以在问题中使用以下语法来实现：

- [ ] Screen width (integer)

- [x] Service worker support

- [x] Fetch support

- [ ] CSS flexbox support

- [ ] Custom elements

输入内容依次是：一个空格，一个破折号，一个空格，一个左方括号和一个空格（或一个x）和一个右方括号，然后又一个空格，最后是一些描述语言。

实际上你可以选中/取消选中这些框！在我看来这种操作很神奇。你可以勾选选择框，它会根据你的选择而更新文本显示选项！如果你在项目板上有这个问题，它也会显示出来：

如果你不懂我所说的 “项目板” 是什么意思，没关系，你就把屏幕往下滑一点就看到了。

招数九：GitHub上的项目板

我一直用Jira做大项目，而对于个人项目，习惯于用Trello。当然了，这两者我都很喜欢。不久前，我知道了GitHub 也有类似的项目板产品，就在我的仓库的“Projects”选项卡上。

上图是我在Trello的任务，我复制了一些已经在Trello上开展的任务到GitHub项目板。

我个人为了方便把它们都添加为笔记。但是，在GitHub中管理任务的功能是与仓库的其余部分集成在一起，因此你可以将现有问题从仓库添加到项目板中。

https://help.github.com/articles/searching-issues-and-pull-requests/

你也可以把现存笔记转化为问题。

你也可以在现有问题的屏幕中，将其添加到右窗格的项目里面。

将“任务”定义与实现该任务的代码存储在同一个仓库中的好处显而易见。这意味着今后你可以在任意一行代码上进行git操作，都能够根据更改记录找回历史代码，而无需在Jira或Trello等其他地方进行跟踪。

不过它也有些缺点，比如功能比较少。你也可以试试 ZenHub，它可以有效地扩展 GitHub。

但是这种做法也有缺点。在过去三周里我GitHub替代Jira来做一个有点看板风格小项目的所有任务。但是，我无法想象在Scrum项目中使用它，无法对这类敏捷开发项目进行适当的开发速度或者其他优点的估算。好消息是，GitHub项目的“功能”很少，因此你不需要花很长时间来评估是否可以切换。所以你可以试玩一下。

我听说过ZenHub可以有效地扩展GitHub，它允许估计你的问题并创建 epics 和依赖。还有速度和燃尽图(burndown charts)，看起来还不错。你可以看看GitHub项目帮助文档：

https://help.github.com/articles/tracking-the-progress-of-your-work-with-project-boards/。

招数十：GitHub WiKi

就像维基百科帮助我们处理对于非结构化的页面集合，GitHub Wiki产品（下面简称Gwiki）在这一点上做得很好。

对于结构化的页面集合，例如你的文档。没有办法说“这个页面是另一页面的子页面”，也没有诸如“下一页”和“上一页”这样的导航按钮。

接下来，我以Gwiki为例，我从NodeJS文档中输入了几页作为wiki页面，然后创建了一个自定义侧边栏，以便我可以模拟一些实际的结构。尽管侧边栏不突出显示你当前的页面，但它在任何时候都在。链接必须手动维护，但总而言之，我认为它会运行的很好。

我的建议：如果你的 README.md 文件超过一个，并且需要几个不同的页面为用户提供指南或者更详细的文档，那么你应该使用 Gwiki。

招数十一：GitHub页面(JekyII)

你可能已经知道可以使用GitHub页面来托管静态网站。如果你还不知道，可以查看资料自己学。本节会特别介绍如何使用Jekyll构建站点。

最简单的是，GitHub页面+Jekyll 将以漂亮的主题呈现你的README.md。例如，我们可以看一下about-github的readme页面：

如果在 GitHub 中点击我的网站的“设置”标签，打开 GitHub 页面，然后选择一个Jekyll主题。

我会看到一个Jekyll主题页面：

我没有实际使用它，但React和Bootstrap主页已经在使用这种方式了。注意，它需要Ruby在本地运行，macOS自带，而Windows需要自行安装。

招数十二：把GitHub当CMS用

假设你的网站中包含一些文字，但你不想将该文本存储在实际的HTML标记中。相反，你希望将文本块存储在某个地方，以便非程序员可以轻松编辑文本。也许用某种形式的版本控制。也许是一个审查过程。

我的建议是：使用存储在仓库中的 markdown 文件来保存文本。然后用你的前端组件抓取这些文本块并将其呈现在页面上。

我是一个React开发者，这里给出一个组件的例子，给定一些的路径，获取、解析和呈现为HTML。

这是我的示例仓库，在/text-snippets中有一些markdown文件。你会使用这样的组件：

现在，GitHub已经成为了一个CMS，可以用来管理你的文本块。

上述示例仅在组件已安装在浏览器中后才能获取markdown。如果你想要一个静态网站，那么你需要服务器对其进行渲染。

没有任何东西可以阻止你从服务器上获取所有的markdown文件（再加上适用于你的缓存策略）。如果沿着这条路走下去，你可能需要查看GitHubAPI以获取目录中所有的markdown文件的列表。