@@ -3642,11 +3642,154 @@ GitHub 上有太多这样的东西,尽管我没有能赶上个好时候,找
3642
3642
3643
3643
试试你的 GitHub 搜索功能吧。
3644
3644
3645
+ # GitHub 获 star 指南
3646
+
3647
+ > 每天打开 GitHub Trending,都是各种面试指南,这样的生活真难受。如果你的项目是金子,那么请读读这篇文章。
3648
+
3649
+ GitHub 是一个非常有意思的地方,也常常变得非常有争议。有证据表明,GitHub 在某种程度上已经成为了简历的一部分。所谓的证据,便是培训班的人在帮助面试者美化 GitHub 页面——从 Vue 高仿各类项目,到淘宝买 star 来粉饰门面。作为一个面试官,我向来是非常讨厌这样的行为。那么作为一个正直的开发人员,他/ 她们也越来越需要通过 GitHub 去证明自己的能力。否则,总有一天** 劣币驱逐良币** ,导致 GitHub Trending 上的项目越来越不堪入目。
3650
+
3651
+ 出于这样的目的,我想为那些有真金白银的小伙伴写一篇攻略。至于其他/ 她人的看法倒是不重要,帮助那些金子从水底浮出来,才是我们应该做的。要是有太多的过于水的项目,每天打开 GitHub Trending,都是各种面试指南,那生活还叫生活吗?那叫被面试强迫的生活。
3652
+
3653
+ ## 为什么我们 star 一个项目
3654
+
3655
+ 在 GitHub 获得 Star 的重点是,** 碰触人们的 G 点** ——人们只对和自己有关的事情感兴趣。或是证明自己是对这个感兴趣,或是觉得这个项目不错可以收藏,或者是觉得作者不容易鼓励一下作者。
3656
+
3657
+ 当然了,我痛恨那些,投机取巧的人——在 GitHub 放置大量非自己创作的电子书、学术资料、课程,以获取 star。
3658
+
3659
+ 获得 Star 的核心是:** 你有人们想要的东西,你分享了人们想要的内容** 。这些内容可以是代码、文档、文章、资料、指南,只要它能帮助到其他/ 她人,那么它便是有价值的。当然了作为 GitHub 本身来说,那些通过 Git 和版本管理可以控制的内容,才更适合于这个平台上。
3660
+
3661
+ 所以,当你手上拥有了人们想要的东西时,那么你就可以使用这份指南,来帮助你构建出更成功的项目。
3662
+
3663
+ ## 我的获 star 方式
3664
+
3665
+ 作为一个 GitHub 上的“大 V ”,我往往不需要花费太多的精力在项目宣传上。在 GitHub 上创建一个项目,然后 star 就来了……。有时候会比较“无耻”,等到某个项目做得稳定的时候,再给自己一个 star ,吸引更多的吃瓜群众。而后,写一系列的文章来介绍自己的项目。唉,做个开源项目不容易啊。
3666
+
3667
+ 但是这些并不管用,因为有时候,我写的代码是大家丝毫不感兴趣的内容。如我最近写的 Serverless 密码管理器 MoPass:我在公众号上、博客上、知乎上写了文章来宣传这个项目,最后只吸引了一小部分人的注意——<= 25 。毕竟,你觉得好的东西,那只是对你来说有用。对于其他/ 她人来说,这个密码管理器可能远远不如 1Password 。
3668
+
3669
+ 再举个成功的例子,最近我在思考:** 新项目的检查清单** ,即当我们来到或者开始一个项目的时候,我们需要做哪些事情,对应的还需要考虑什么因素。于是我在 GitHub 上创建了一个名为 New Project Checklist ([https: // github.com/phodal/new-project-checklist](https://github.com/phodal/new-project-checklist) ) 的项目。我只是按自己的想法,在 README 上写下了要考虑的中英文因素,还没编写 Web 部分,就已经获得了 100+ 的 star。与此同时,因为 Web 部分还没完成,所以我还没在我的博客、专栏上进行宣传。
3670
+
3671
+ 我只是写了一个 README ,然后 star 就来了。但是,一般情况下,我们需要怎么做呢?
3672
+
3673
+ ## GitHub 流量分析
3674
+
3675
+ 实际了,当我们在说获得 star 的时候,我们说的是** 为自己的项目做推广** 。只是呢,获得 star 是其中的一个结果产物,也就是说,我们在宣传项目的过程中,获得了关注度。至于推广本身来说,不同的人会有不同的看法。
3676
+
3677
+ 事实上,GitHub 获取 star 与我们日常了解的营销差不多,先将用户吸引到我们的 GitHub 页面,再让用户有关注的动力(这一点太难了)。
3678
+
3679
+ 因此开始之前,我们先看张图就能知道怎么获取流量。如下是《GitHub 漫游指南》最近两周内的流量来源统计(GitHub 通过 Google Analysis 来统计):
3680
+
3681
+ ! [GitHub 漫游指南](./ img/ github_traffic .png )
3682
+
3683
+ 从上图中可以看出,流量主要来源于几部分:
3684
+
3685
+ - GitHub 项目的直接访问
3686
+ - GitHub 的直接访问
3687
+ - 来源于知乎等社交网站的
3688
+ - 来自于 GitHub Pages 的访问
3689
+ - 来自其它社交网站的访问
3690
+
3691
+ 总的来说,在这一周里,累计有 1 ,266 次访问,其中有 735 个独立访客。看这数据不错,而实际上 star 率 就有点低。根据 Star History 网站(https: // star-history.t9t.io ) 的统计,在过去的近两个月里,才涨了 38 个 star。
3692
+
3693
+ ! [GitHub 漫游指南 Star 历史](./ img/ github- star- history .png )
3694
+
3695
+ 从我的分析来看,大抵原因有两个:
3696
+
3697
+ 1. 用户看的都是 GitHub Pages 上的内容
3698
+ 2. 从数量上来看,受众并不多
3699
+
3700
+ 而我最近在玩的 New Project Checklist ([https: // github.com/phodal/new-project-checklist](https://github.com/phodal/new-project-checklist) 的转化率看上去,还算可以:
3701
+
3702
+ ! [GitHub New Project Checklist](./ img/ github- new - project- checklist .png )
3703
+
3704
+ 在 999 个独立访客里,获得了 202 个 star,转化率差不多是 20 % ——大家真的对这个项目感兴趣。
3705
+
3706
+ 所以,让我们再强调一下核心的部分:** 你分享了人们想要的代码、内容** 。否则,你带来了大量的流量,并不一定能转化为你想要的关注度。
3707
+
3708
+ ## GitHub 获 star 指南技巧
3709
+
3710
+ 对于一个创造而言,自然而然的希望自己的项目能有人用。可能一点点的吐槽,都能帮助项目以更好的方式前进。这也就是我为自己项目宣传的意义,在创建项目的时候,我们往往只会按照自己的需要来创建项目。而非其他/ 她人的需求。因此当有一些新的需求出现时,可能会稍微地影响项目演进的方向。这些方向有好有坏,有时候反而会对自己更有帮助。
3711
+
3712
+ 好了,回到我们的正题上,怎么去获取 star?
3713
+
3714
+ ### 技巧一:结合 SEO 技巧
3715
+
3716
+ 当我们在为一个项目做宣传的时候,实际上我们做的事情类似于搜索引擎优化(Search Engine Optimization)。稍有不同的是,GitHub 在实践的过程中,帮助我们优化了很多细节。它可以让我们更关注于核心的要素。
3717
+
3718
+ 实际上,在上一小节里,我们已经介绍了相关的内容。若是想获得来自于 Google 等搜索引擎的访问,那么要掌握的技巧有:
3719
+
3720
+ ! [Google New Project Checklist](./ img/ google- new - project- checklist .png )
3721
+
3722
+ - 简单实用的项目名。项目名在 Google 搜索结果里是放在最前面的部分,它与 URL 同在。
3723
+ - 写好项目的 ` ` Description` ` 。不管怎样,你一定要为你的项目写好 Description,让看到的人知道它在做什么。
3724
+ - 设置好相应的 ` ` topics` ` 。GitHub 为项目设计了一个 Topics 页面,这些页面会被拉入相应的索引中,可以从 Google 等搜索引擎和 GitHub 中搜索到。
3725
+ - 作为外链加入文章中。作为 SEO 技巧的一部分,你需要在你的博客和文章里,适当地引用你的 GitHub 项目,它会你的项目带来流量。
3726
+ - 合适的外链标题。作为链接存在时,需要注意链接的标题(与项目主题一致),它会在某种程度上影响搜索结果。
3727
+
3728
+ 这些只是一些基本的内容,算不上是技巧,但是做好基础很重要。
3729
+
3730
+ ### 技巧二:完整、易读的 README
3731
+
3732
+ 让我们再强调一下,好的 README 真的很重要,重要、重要!重要。
3733
+
3734
+ GitHub 是一个人的简历,** 而开源项目的 README ,就好像是一个项目的简历** 。在这份简历里,你需要好好地写你的项目:
3735
+
3736
+ - ** 这个项目做什么?** ?
3737
+ - ** 它解决了什么问题** ?
3738
+ - ** 它有什么特性 — hello, world 示例** ?
3739
+ - ** 怎么使用这个项目** ?
3740
+ - ** 这个项目使用的是什么协议** ,是否允许商用?
3741
+
3742
+ 以我混迹在 GitHub 近 10 年的经验来看,老外** 最喜欢吹这个项目有什么特性了** 。与此同时,还会在这个项目上“画大饼”(Roadmap),即** 这个项目未来将有什么功能** ——为了实现这些功能,我们还需要你的关心、支持与厚爱。所以,如果你是在做一个惊天动地的项目,比如说你要实现一个自动化安装脚本,你可以在未来的功能里写上:
3743
+
3744
+ - AI 自动化安装(TODO )
3745
+
3746
+ 这确实是个 TODO ——即不吹,又吸引吃瓜群众。
3747
+
3748
+ ### 技巧三:社交分享
3749
+
3750
+ 作为一个混迹在各个社区的资深技术咨询师,分享相关的项目是我的一个常规操作。特别是,当看到一些人“无聊的聊天”,就会推荐上自己的新项目。当然,一般一个项目只会有一两次,频繁的分享便相当于 ** ,你懂的。
3751
+
3752
+ ** 更新状态** 。当我在写一个大家感兴趣的开源项目时, 我会在我的社交账号上,如微博、知乎想法,定期的更新相关的状态。诸如:
3753
+
3754
+ ! [微博 MoPass](./ img/ mopass- weibo .png )
3755
+
3756
+ 万一有人感兴趣,就会随之而来——主要是我也不知道微博要怎么玩。
3757
+
3758
+ ** 推荐自己的项目** 。作为一个在 GitHub 上有大量项目的开源作者,以及拥有大量文章的我。每次在微信群里,看到一些相关的问题,都会直接丢出我的开源项目。既装逼,又靠谱。
3759
+
3760
+ 至于微信群的分享频率,要适度~ ,适量~ 。
3761
+
3762
+ ### 技巧四:文章
3763
+
3764
+ 既然我写了一个这么好的开源项目,那么最好的方式,还是写一篇文章介绍一下这个项目吧。blabla,写完了一篇项目的使用文档:
3765
+
3766
+ - ** 为什么需要这个项目?**
3767
+ - ** 这个项目是什么?**
3768
+ - ** 这个项目能解决什么问题?**
3769
+ - ** 这个项目要怎么用啊?**
3770
+
3771
+ 是不是写起来很简单?
3772
+
3773
+ 未来在其它的文章中,有一些相关的话题,便可以稍微提及一些相关的项目。比如,在这篇文章里,我还介绍了好几个近期的项目。这些文章,除了在我的公从号上,还会发在我的博客(累计 100 万访问量)上,我的知乎专栏上,还有我的……上。它们结合起来,会形成一股强大的力量,即能吸引用户,又能在 SEO 上有一定的提升。
3774
+
3775
+ ### 技巧五:把握 GitHub Trending
3776
+
3777
+ 万一,我是说万一,你的项目上了 GitHub Trending。截个图,然后你可以再写一篇文章( 我的项目是如何上 GitHub Trending,毕竟上 Trending 很简单),发一条微博,写一个想法,录个小视频,大家快来看这是我的项目。
3778
+
3779
+ 理论上上 GitHub Trending 会吸引来更多的用户——有大量的网站、自动化微博等,会每天去介绍这些新的上的 Trending 项目,没有意外的话,它会为你带来更多的流量——意味着更多的关注度。
3780
+
3781
+ ### 不是技巧的技巧:持续性
3782
+
3783
+ 事实上,如你所知,我在 GitHub 上获得大量 star 的原因,并不是说我有一个优秀的项目。而在于我在持续的更新,持续不断地在 GitHub 上做自己喜欢的项目,投入时间分享相关的技巧,还有一系列相关的开源项目。
3784
+
3785
+ 我们一直在持续变好,打造一个自由的互联网世界,打造一个个自己喜欢的工具。
3786
+
3787
+ 我们是极客,我们热爱编程,我们热爱分享。
3788
+
3645
3789
FAQ
3646
3790
===
3647
3791
3648
- 如何看待github 项目刷Star行为?
3649
- -- -
3792
+ ## 如何看待github 项目刷Star行为?
3650
3793
3651
3794
我觉得:在作者开源了源码的情况下,求 star 并没有任何问题。
3652
3795
0 commit comments