【译】你能够用GitHub作的12件 Cool 事情

原文连接

1 在 GitHub.com 编辑代码

我将从我认为你们都知道的一件事情开始(尽管我是直到一周前才知道)。

当你在 GitHub 查看文件时(任何文本文件，任何仓库中)，右上角会有一个小铅笔图标，点击它就能够编辑文件了。完成以后点击 Propose file change 按钮 GitHub 将会自动帮你 fork 该项目而且建立一个 pull request 。

很厉害吧！他自动帮你 fork 了该 repo。

再也不须要 fork , pull ,本地编辑再 push 以及建立一个 PR 这样的流程了。

这很是适合修复编写代码中出现的拼写错误和修正一个不太理想的想法。

2 粘贴图片

你不只仅受限于输入文本和描述问题，你知道你能够直接从粘贴板中粘贴图片吗？当你粘贴时，你会看到图片已经被上传了(毫无疑问被上传到云端)以后会变成 Markdown 语法来显示图片。

3 格式化代码

若是你想写一段代码，你能够三个反引号开始 —— 就像你在研究MarkDown时所学到的 —— 以后 GitHub 会试着猜想你写的语言。

但若是你写了一些相似于 Vue, Typescript, JSX 这样的语言，你能够明确指定获得正确的高亮。

注意第一行中的

```jsx复制代码

这意味着代码段将会呈现出:

(这个扩展于 gists 。顺便说一句，若是你使用 .jsx 后缀，就会获得JSX的语法高亮)

这是一个全部受支持的语法列表。

4 在 PR 中用关键词关闭 Issues

假设你建立了一个用于修复 Issues #234 的 PR ,你能够在你 PR 的描述中填写 fixes #234 (或是在你 PR 任意评论中填写都是能够的)。
以后合并这个 PR 时将会自动关闭填写的 Issues。怎么样,很 cool 吧。

了解是更多相关的内容。

5 连接到评论

你是否有过想要连接到特殊 comment 的想法但却没法实现？那是由于你不知道怎么作。朋友那都是过去式了，如今我就告诉你，点击用户名旁边的日期/时间便可连接到该 comment 。

6 连接到代码

我知道你想连接到具体的代码行上。

尝试:查看文件时，点击代码旁边的行号。

看到了吧，浏览器的 URL 已经被更新为行号了。若是你按住 shift,同时点击其余行号，URL 再次被更新，而且你也高亮显示页面中的一段代码。

分享这个 URL ，访问时将会连接到该文件已经选中的那些代码段。

但等一下，那指向的是当前的分支，若是文件发生了改变呢？也许一个在当前状态链接到文件的永久链接正是你想要的。

我很懒，因此用一张截图展现以上的全部操做。

谈到网址。。。

7 像命令行同样使用 GitHub 连接

使用 GitHub 自带的 UI 浏览也还不错，但有时直接在 URL 中输入是最快的方法。好比，我想跳转到我正在编辑的分支并和 master 进行对比，就能够在项目名称后面接上 /compare/branch-name 。

与选中分支的对比页将会显示出来:

以上就是和 master 分支的差别，若是想要合并分支的话，只须要输入 /compare/integration-branch...my-branch 便可。

你还能够利用快捷键达到一样的效果，使用 ctrl + L 或者 cmd + L 能够将光标移动到 URL 上(至少在 Chrome 中能够)。 加上浏览器的自动补全 —— 你就能够在两个分支之间轻松切换了。

8 在Issues建立列表

你想在你的 issue 中看到复选框列表吗?

你想在查看 issue 列表是它们以好看的 2 of 5 进度条呈现吗？

太好了！你能够用如下语法来建立一个交互性的复选框:

- [ ] Screen width (integer)
 - [x] Service worker support
 - [x] Fetch support
 - [ ] CSS flexbox support
 - [ ] Custom elements复制代码

是由一个空格、中横线、空格、左括号、空格(或者是 X )、右括号、空格以及一些文本组成。

你甚至能够真正的 选中/取消 这些复选框！基于某些缘由，对于我来讲你看起来像是技术魔力。是真的可以选中这些复选框！甚至它还更新了底层源码。

ps：如下包括第九点 基于GitHub的项目面板 因为用的很少就没有翻译。

10 GitHub wiki

做为一个像维基百科那样的非结构化的页面集合， GitHub Wiki的供给(我把它称之为 Gwiki ) 是一个很是棒的功能。

对于结构化的页面来讲 —— 例如你的文档：不能说这个页面是其余页面的子页面，或则是有 “下一节”，“上一节” 这样的便捷按钮。而且 Hansel 和 Gretel 也没有，由于结构化页面并无 breadcrumbs 这样的设计。

咱们继续，让 Gwiki 动起来，我从 NodeJS 的文档中复制了几页来做为 wiki 页面。而后建立了一个自定义侧边栏，帮助我更好地模拟一些实际的目录结构。尽管它不会突出显示你当前的页面位置，但侧边栏会一直存在。

这些连接须要你手动维护，但总的来讲，我认为它能够作得很好。 若是须要的话能够看看。

虽然它与 GitBook ( Redux 文档所使用的)或者是定制网站相比仍有差距。但在你的 repo 中它有 80% 彻底值得信赖的。

个人建议是: 若是你已经有多个 README.md 文件，而且想要一些关于用户指南或更详细的文档的不一样的页面，那么你应该选择 Gwiki。

若是缺少结构化/导航开始让你不爽的话，那就试试其余的吧。

11 GitHub Pages

你可能已经知道使用 GitHub Pages 来托管一个静态网站。若是你不知道，如今就来学习，这一节是专门用于讨论使用 Jekyll 来构建一个站点的。

最简单的就是： GitHub Pages + Jekyll会经过一个漂亮的主题来渲染你的 README.md 文件。例如:经过 about-github 来查看的个人 README 页面。

若是我在 GitHub 中点击了 settings选项，切换到 Github Pages 设置，而后选择一个 Jekyll theme。。。

我就能够获得 Jekyll-themed 页面。

从这点上我能够主要依据易编辑的 Markdown 文件来构建一个完整的静态站点。本质上是把 GitHub 变成了 CMS。

虽然我没有实际使用过，可是 React Bootstrap 的网站都是使用它来构建的。因此它不会糟糕。

注意:它要求 Ruby 运行本地环境( Windows 自行安装， macOS 自带)。

12 把 GitHub 当作 CRM 使用

假设你有一个存有一些文本内容的网站，你不想将文本内容存储于真正的 HTML 源码中。

相反的，你想要将这些文本块存储于非开发人员能轻松的进行编辑的地方。多是一个版本控制系统，甚至是一个审核流程。

个人建议是:使用 GitHub 厂库中的 Markdown 文件来存储这些文本内容，而后使用前端组件来拉取这些文本块并展现在页面上。

我是搞 React 的，因此这有一个 解析 Markdown 的组件例子，给定一些 Markdown 文件路径，它将会自动拉取并做为 HTML 显示出来。

class Markdown extends React.Component {
    constructor(props) {
      super(props);

      // replace with your URL, obviously
      this.baseUrl = 'https://raw.githubusercontent.com/davidgilbertson/about-github/master/text-snippets';

      this.state = {
        markdown: '',
      };
    }

    componentDidMount() {
      fetch(`${this.baseUrl}/${this.props.url}`)
        .then(response => response.text())
        .then((markdown) => {
          this.setState({markdown});
        });
    }

    render() {
      return (
        <div dangerouslySetInnerHTML={{__html: marked(this.state.markdown)}} />
      );
    }
}复制代码

奖励环节 —— GitHub 工具

我已经使用了 Octotree Chrome extension 有段时间了，如今我向你们推荐它！
不管你是在查看哪一个 repo 它都会在左侧给你一个树状面板。

经过这个视频我了解到了 octobox，它是用于管理你的 GitHub Issues 收件箱，看起来至关不错！
以上就是我针对于octobox的所有想法。

其余

就是这样了！我但愿这里至少有三件事是你还不知道的。

最后: hava a nice day！

我的博客：crossoverjie.top。