大四上的时候，我开始在 GitHub 上开源并维护一个叫做 PicGo 的应用。其实一开始跟很多小伙伴一样，只是觉得 GitHub 只是个用来开源代码的地方。但是随着一点点深入的使用，我发现 GitHub 提供给开发者的功能，已经超出了我一开始的认知。如今我利用 GitHub 提供的免费能力，已经完成了从代码开源、持续集成、收集反馈、应用分发等一系列工作。在本文中我将结合我自身的经验，给你带来 GitHub 的一些你可能不知道的小技巧。
开源，是 GitHub 最最基本的一个能力。为什么不说是代码开源，是因为这里其实还有很多有意思的东西，它们并不是代码，但是在 GitHub 上也能算作一种开源。所以我觉得在 GitHub 上开源的，应该说是你的想法。这里列举几个非代码类的开源项目，都挺有意思：
所以只要你想，你可以把你的想法，以文本、代码或者其他作品的形式，开源到 GitHub 上。所以不要再说 GitHub 是码农的天地，其实作为一个普通用户，你也可以使用 GitHub。
当然如果你不想开源？没问题，创建一个私有（private）仓库，这样你上传自己的一些东西，别人也看不见了。
其实这个功能现在已经有很多人用上了，那就是用 GitHub 来做一个个人博客。此类教程已经烂大街，我就不再赘述。但是很多人不知道，其实每个 GitHub 仓库，都可以生成一个网站，可以用来作为文档网站、介绍网站等等。它就是利用了跟建立个人博客一样的叫做 GitHub Pages 的功能。
在以前，想要为一个仓库做一个 GitHub Pages，需要专门建立一个叫做 gh_pages 的分支，或者使用一个叫做 docs 的文件夹，里面存放你想展示的网页的html、css、js等资源，这样才能自动生成一个对应的网页。但是现在 GitHub 已经越来越方便，你可以在项目的 Settings -> Pages 里选择你想指定成网页的分支名与文件夹路径：
更多的内容，可以参考 GitHub Pages 的官方文档。
这里我列举几个我自己利用这个功能建立的网站：
issues本来是用来收集用户反馈的工具。不过到了现在，无论是你的博客想要一个评论系统，还是你的应用想要了解用户需求、Bug反馈，还是想要规划项目进度等等，issues都是你应该用起来的工具。
issues里可以发issue，这是众所周知的。issue可以是用户创建的，也可以是你自己创建的。可以通过 label（标签）、milestone（里程碑）、projects（项目）等工具，来对不同的issue做区分、做项目规划。
首先最常用的大概就是 label 了，用 label 可以给项目的 issues 打上不同的标签：
这样通过指定不同的 label，我们能快速定位到同类标签的issue，这样寻找反馈的速度又能大大提高：
然后是用来推进项目的 milestone 和 projects，milestone 我用的不多，但是功能跟 projects类似，我这里以 projects 为例：
projects里，一般是以kanban的形式来组织的。内容可以是已经存在的issue，也可以是自己新建的内容。常用的projects kanban有几种状态： To do、In progress、Done。不同状态的 kanban 项会以不同颜色的进度条来体现，To do 为灰色，In progress 为紫色，Done 为绿色，很清晰。
通过这个工具，开发者可以用来规划自己项目的进度，使用者能对项目的进度一目了然。同时在具体的issue里，也能在右侧看到该 issue 所挂载的对应的 projects、label、milestone等信息，做到了双向联动。
虽然购买一个云服务器的钱还是有的，但是对于做应用分发来说，PicGo安装包至少几十MB的体积，支付于网络带宽的费用将会远远超过云服务器本身，对于当时还是学生党而言的我，这个自然是没有办法承受的。那 PicGo 是如何做应用分发的？其实就是利用了 GitHub 的 release 功能。简单来说，每个应用基本上都会有版本号的概念。对应到 git 中，版本号通常是一个 tag 。GitHub 基于 tag 信息，可以在 release 页中创建基于某个 tag 的发行版，同时可以以附件的形式，将一些文件挂载到这个发型版上，从而实现了应用分发：
应用分发可以实现了，但是应用构建该怎么办？从源代码到最终用户可用的应用，往往需要一个测试、构建的过程。早期的 PicGo 是「人肉」来做这件事的。代码发布后，我手动在 macOS、windows的机器上构建 PicGo，然后再将构建好的安装包通过 release 页上传，从而实现应用分发。
但是这样做有几个很难以接受的点：
于是你可以看到，一开始 PicGo 只有 macOS 平台，后来加入了 windows，又后来加入了Linux的支持。之所以能够同时支持三个平台，除了electron本身特性之外，还因为我发现了 CI\CD系统，它解放了我的双手，让我基本可以只专注于代码本身，而不用再手动去构建和分发应用了。
什么是CI（持续集成）\CD（持续部署）？简单来说，从代码提交到最终上线的应用，会有一系列的过程（合并代码分支、测试、构建应用、部署或者发布应用等等）。而这一系列的过程，就包含了持续集成和持续部署。通常来说会有一个系统来帮你做这些事，这个系统就叫做持续集成系统。而对于 GitHub 来说，早期的 GitHub 没有自己的持续集成系统。我们通常会使用一些和 GitHub 有合作的持续集成服务提供商。比如我自己在用的 travis-ci （可用于集成的平台 macOS、Linux）、Appveyor （可用于集成的平台 windows），就能够绑定某个 GitHub 仓库，然后通过一些配置（比如在某个代码分支推送到 GitHub 时，触发某个命令来构建并发布应用到 GitHub release），实现你需要的持续集成能力。
对于 PicGo ，travis-ci 会在我每次往 master 分支推送代码的时候，自动执行我预先配置好的命令，构建并将 PicGo 的 Linux 、macOS 安装包推送到 release 的 Assets中，同时 Appveyor 也会做同样的事，只不过它构建的产物是 windows 平台的。
现在 GitHub 已经有了自己的CI\CD工具，那就是 GitHub Actions 。由于是自家的东西，和自家结合地更加紧密，我自己体验下来，不仅速度更快，平台也支持更全（三家平台都支持），还有很多开源的 Actions 可以搭配使用，同时对于私有仓库也有一定的免费额度。其他第三方的CI\CD平台，基本只对开源项目免费，都私有项目基本都是收费的（不然怎么赚钱呀）。现在如果你让我推荐在 GitHub 上使用的 CI\CD 工具，我一定直接推荐你 GitHub Actions。
Discussions 是 GitHub 推出没多久的产品。正如它的中文翻译（讨论区）一样，这是一个比 issues 更加开放的区域。
往往我们在 issues 区会更关注于 feature request、bug report 等本身，对于一些应用本身的讨论，以前的我不喜欢让它出现在 issues 里。因为这样做让一些来 issues 查找问题解决方案的小伙伴不能快速定位。所以以前 PicGo 项目采用了 gitter 作为讨论群。当然也有很多项目是用微信群、QQ群等来做用户群的。不过我自己本身不喜欢微信太吵闹，所以我一直用着第三方平台。
直到 GitHub 推出了 Discussions，让我可以彻底放弃 gitter 了。Discussions 以话题为单位，类似知乎一样，可以有点赞、选为答案等操作：
同时它带有楼中楼的回复形式，比起issues会更有互动感：
不过要构建一个属于自己作品的社区，还需要一些时间来做运营，引导用户在 Discussions 里发帖、讨论等等，这一点来说我还有待加强。我自己感觉比较理想的情况是大家可以在 Discussions 区发表一些对 PicGo 的使用技巧、 使用PicGo的一些经验、遇到错误的一些解决办法等等。这样后续的用户就会在 Discussions 区域找到很多关于 PicGo 的使用指南，甚至有机会也会自己发表话题来回馈社区，类似于 JSBox官方社区 的作用一样。
说了这么多，其实就是想说 GitHub 作为一个平台，已经提供给了我们足够多工具、能力，让我们能够去发挥自己的创意，为大家带来更多有意思的分享、应用和讨论。用好 GitHub 不仅仅只是把它当做一个开源代码仓库而已，还是需要把各个工具灵活运用，才能达到良好的效果。
哦对了，如果你问我，从 PicGo 写下第一行代码，到现在已经13k star，有没有为此花过钱做分发做推广。我想说，因为我的项目是开源的，所以我享受到了来自开源世界最大的福利，我所使用的工具都是免费的，所以到目前为止我的花费是0元。感谢 GitHub 等平台对开源的极大支持，也感谢你能看完这篇文章，希望对你能有所帮助。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。