大四上的时候,我开始在 GitHub 上开源并维护一个叫做 PicGo 的应用。其实一开始跟很多小伙伴一样,只是觉得 GitHub 只是个用来开源代码的地方。但是随着一点点深入的使用,我发现 GitHub 提供给开发者的功能,已经超出了我一开始的认知。如今我利用 GitHub 提供的免费能力,已经完成了从代码开源、持续集成、收集反馈、应用分发等一系列工作。在本文中我将结合我自身的经验,给你带来 GitHub 的一些你可能不知道的小技巧。

把你的想法开源

开源,是 GitHub 最最基本的一个能力。为什么不说是代码开源,是因为这里其实还有很多有意思的东西,它们并不是代码,但是在 GitHub 上也能算作一种开源。所以我觉得在 GitHub 上开源的,应该说是你的想法。这里列举几个非代码类的开源项目,都挺有意思:

  1. 杭州买房宝典:https://github.com/houshanren/hangzhou_house_knowledge
  2. 996.ICU:https://github.com/996icu/996.ICU
  3. 好耶 是女装:https://github.com/komeiji-satori/Dress

所以只要你想,你可以把你的想法,以文本、代码或者其他作品的形式,开源到 GitHub 上。所以不要再说 GitHub 是码农的天地,其实作为一个普通用户,你也可以使用 GitHub。

当然如果你不想开源?没问题,创建一个私有(private)仓库,这样你上传自己的一些东西,别人也看不见了。

给你的想法加一个官方网站

其实这个功能现在已经有很多人用上了,那就是用 GitHub 来做一个个人博客。此类教程已经烂大街,我就不再赘述。但是很多人不知道,其实每个 GitHub 仓库,都可以生成一个网站,可以用来作为文档网站、介绍网站等等。它就是利用了跟建立个人博客一样的叫做 GitHub Pages 的功能。

在以前,想要为一个仓库做一个 GitHub Pages,需要专门建立一个叫做 gh_pages 的分支,或者使用一个叫做 docs 的文件夹,里面存放你想展示的网页的html、css、js等资源,这样才能自动生成一个对应的网页。但是现在 GitHub 已经越来越方便,你可以在项目的 Settings -> Pages 里选择你想指定成网页的分支名与文件夹路径:

GitHub Pages 设置

更多的内容,可以参考 GitHub Pages 的官方文档

这里我列举几个我自己利用这个功能建立的网站:

  1. MARKSZのBlog (我的博客):https://molunerfinn.com/
  2. PicGo的官方网站:https://molunerfinn.com/PicGo/
  3. 每天更新的我的项目的Top 20 Star 列表:https://molunerfinn.com/github-stars-reminder/
  4. 本科毕设时做的3D齿轮演示系统:https://molunerfinn.com/Gear-system/Gear-system/index.html

利用issues推进你的项目

issues本来是用来收集用户反馈的工具。不过到了现在,无论是你的博客想要一个评论系统,还是你的应用想要了解用户需求、Bug反馈,还是想要规划项目进度等等,issues都是你应该用起来的工具。

issues里可以发issue,这是众所周知的。issue可以是用户创建的,也可以是你自己创建的。可以通过 label(标签)、milestone(里程碑)、projects(项目)等工具,来对不同的issue做区分、做项目规划。

首先最常用的大概就是 label 了,用 label 可以给项目的 issues 打上不同的标签:

Labels工具

这样通过指定不同的 label,我们能快速定位到同类标签的issue,这样寻找反馈的速度又能大大提高:

选择指定的 label
指定 label 的展示结果

然后是用来推进项目的 milestone 和 projects,milestone 我用的不多,但是功能跟 projects类似,我这里以 projects 为例:

projects

projects里,一般是以kanban的形式来组织的。内容可以是已经存在的issue,也可以是自己新建的内容。常用的projects kanban有几种状态: To do、In progress、Done。不同状态的 kanban 项会以不同颜色的进度条来体现,To do 为灰色,In progress 为紫色,Done 为绿色,很清晰。

projects详情页

通过这个工具,开发者可以用来规划自己项目的进度,使用者能对项目的进度一目了然。同时在具体的issue里,也能在右侧看到该 issue 所挂载的对应的 projects、label、milestone等信息,做到了双向联动。

issue和projects、label等联动

利用CI\CD构建并分发应用

虽然购买一个云服务器的钱还是有的,但是对于做应用分发来说,PicGo安装包至少几十MB的体积,支付于网络带宽的费用将会远远超过云服务器本身,对于当时还是学生党而言的我,这个自然是没有办法承受的。那 PicGo 是如何做应用分发的?其实就是利用了 GitHub 的 release 功能。简单来说,每个应用基本上都会有版本号的概念。对应到 git 中,版本号通常是一个 tag 。GitHub 基于 tag 信息,可以在 release 页中创建基于某个 tag 的发行版,同时可以以附件的形式,将一些文件挂载到这个发型版上,从而实现了应用分发:

release页上传文件
上传后的文件将会在 Assets 列表中出现

应用分发可以实现了,但是应用构建该怎么办?从源代码到最终用户可用的应用,往往需要一个测试、构建的过程。早期的 PicGo 是「人肉」来做这件事的。代码发布后,我手动在 macOS、windows的机器上构建 PicGo,然后再将构建好的安装包通过 release 页上传,从而实现应用分发。

但是这样做有几个很难以接受的点:

  1. 每次应用发布前需要自己手动构建,费时费力
  2. 遇到自己手头没有的平台(比如 Linux),那么我将无法构建这个平台的应用
  3. 构建时所需要的一些环境变量等,一旦我换了一台电脑,将要重新配置一遍

于是你可以看到,一开始 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构建属于你的作品的社区

Discussions 是 GitHub 推出没多久的产品。正如它的中文翻译(讨论区)一样,这是一个比 issues 更加开放的区域。

往往我们在 issues 区会更关注于 feature request、bug report 等本身,对于一些应用本身的讨论,以前的我不喜欢让它出现在 issues 里。因为这样做让一些来 issues 查找问题解决方案的小伙伴不能快速定位。所以以前 PicGo 项目采用了 gitter 作为讨论群。当然也有很多项目是用微信群、QQ群等来做用户群的。不过我自己本身不喜欢微信太吵闹,所以我一直用着第三方平台。

直到 GitHub 推出了 Discussions,让我可以彻底放弃 gitter 了。Discussions 以话题为单位,类似知乎一样,可以有点赞、选为答案等操作:

Discussions

同时它带有楼中楼的回复形式,比起issues会更有互动感:

Discussions楼中楼

不过要构建一个属于自己作品的社区,还需要一些时间来做运营,引导用户在 Discussions 里发帖、讨论等等,这一点来说我还有待加强。我自己感觉比较理想的情况是大家可以在 Discussions 区发表一些对 PicGo 的使用技巧、 使用PicGo的一些经验、遇到错误的一些解决办法等等。这样后续的用户就会在 Discussions 区域找到很多关于 PicGo 的使用指南,甚至有机会也会自己发表话题来回馈社区,类似于 JSBox官方社区 的作用一样。

小结

说了这么多,其实就是想说 GitHub 作为一个平台,已经提供给了我们足够多工具、能力,让我们能够去发挥自己的创意,为大家带来更多有意思的分享、应用和讨论。用好 GitHub 不仅仅只是把它当做一个开源代码仓库而已,还是需要把各个工具灵活运用,才能达到良好的效果。

哦对了,如果你问我,从 PicGo 写下第一行代码,到现在已经13k star,有没有为此花过钱做分发做推广。我想说,因为我的项目是开源的,所以我享受到了来自开源世界最大的福利,我所使用的工具都是免费的,所以到目前为止我的花费是0元。感谢 GitHub 等平台对开源的极大支持,也感谢你能看完这篇文章,希望对你能有所帮助。