怎样让你的 GitHub 365 天都保持全绿?

2024-05-15 12:32
文章标签 365 怎样 github 保持 全绿

本文主要是介绍怎样让你的 GitHub 365 天都保持全绿?,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

这是「进击的Coder」的第 342 篇技术分享

作者:崔庆才

来源:崔庆才丨静觅

阅读本文大概需要 5 分钟。


写这篇文章的缘由来自看到了知乎上的一个问题——在 GitHub 上保持 365 天全绿是一种怎样的体验?

解释

大家可能有的不明白啥意思啊,这个绿指的是就是 GitHub 的 Contribution,如果你每天都提交代码到 GitHub,至少一次 commit,那么 GitHub 就会在你当天对应的 Contribution 格子上点上绿色,比如我的就是这样子:

因为我经常在 GitHub 上提交代码,所以我的 Contribution 页面就显示为绿色,commit 多的就深,少的就浅,灰色的就是当然没有任何代码提交的。

所以这个问题问的就是,每天都在 GitHub 上提交代码是什么体验,也就是 365 天每天一天不落地撸代码是什么体验?

然后有一个回答看得我笑出声:

曾经保持了200多天全绿,但是冷落了女朋友,一直绿到现在。

原回答如下:

这哥们真的是太秀了,秀到我实在忍不住给他默默点了个赞...

不过咱们还是言归正传啊,说回这个问题。

其实说实话真的保持 365 天全绿真的是一件很难的事情,每周都会有周末吧,周末得陪女朋友吧?什么,你没有女朋友,那忽略这一条。

那即使没有女朋友,一年不得有几天是过年过节的,还撸啥代码啊?即使不是逢年过节,那也总有几天状态不好或者生病的吧,强如铁人那坚持 365 天天撸代码也是够神的。

不过我还真见过几个,实打实的大神,比如 Taylor Otweel,PHP Laravel 框架的开发者,一年 8000 多次 commit,他的 Contribution 是这样的:

这个是真的强,而且人家撸的代码质量肯定也高啊,不像我们可能改了点 README 啥的。

但强如 Taylor Otweel,你也能看到有些天是没有贡献的,毕竟人家周末可能就真的不撸代码或者有其他的安排。

那怎么才能做到 365 天全绿呢?

既然人不行,那就靠机器人吧。

GitHub 不是这两年出了个 GitHub Actions 的功能吗?这就是 CI 嘛,借助于它,我们想做到 GitHub 365 天全绿,就轻而易举了。

到底怎么做?难不难。

不难,可能只需要两分钟就搞定了。

想不想知道怎么做的?想知道的接着往下看。

方案

这里介绍一个 GitHub 的库,地址为:https://github.com/justjavac/auto-green,借助它,咔咔几步就能搞定了。

先说步骤。

首先打开这个仓库,点 Use this template,注意千万不要点 Fork,不然是不生效的,如图所示:

点了之后就是提示你用这个 Template 创建一个自己的 Git 仓库,这时候就会让你填写的的仓库名称,比如我就创建了一个名字叫做 AutoGreen 的仓库,如图所示:

至此,已经成功了一半了。

现在你会观察到,在 Actions 这个选项卡自动执行了一个任务。啪!很快啊,执行完了:

执行完了你会发现这个仓库多了一次 commit,是来自 justjavac 的一次 commit:

点进去看看,commit 的信息还叫 "a commit a day keeps your girlfriend away",啥意思?

跟代码做好朋友,永远没有女朋友???Oh,No,不是这样的!

commit 如图所示:

神奇的是这次 commit 还没有任何 file change,还是个空的 commit。

行了,不管这么多了。

到现在就结束了吗?GitHub 以后就会天天绿了吗,当然不会绿啊,为啥啊?

扒一扒源码看一下,打开 .github/workflows/ci.yml 文件,结果如下:

代码:

name: cion:push:branches:- masterschedule:- cron: "0 0 * * *"jobs:autogreen:runs-on: ubuntu-lateststeps:- name: Clone repositoryuses: actions/checkout@v2- name: Auto greenrun: |git config --local user.email "justjavac@gmail.com"git config --local user.name "迷渡"git remote set-url origin https://${{ github.actor }}:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}git pull --rebasegit commit --allow-empty -m "a commit a day keeps your girlfriend away"git push

看看这个文件,意思就是每天执行一下下面的这几行代码,比如 git 的 config、commit、push 等,就相当于模拟了一次提交。

其中有几行代码比较有意思:

git remote set-url origin https://${{ github.actor }}:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}

这里就是指定远程仓库等地址,这里有几个占位符,github 的 actor 和 repository 对象,其实这些我们不用管,在运行的时候会被自动赋值为当前仓库的信息,另外还有 GITHUB_TOKEN 也是在该任务运行的时候自动添加的。

另外还有一行代码:

git commit --allow-empty -m "a commit a day keeps your girlfriend away"

这里的 commit 操作加上了一个 --allow-empty 选项,意思就是允许空的提交,这也就解释了上文空提交的缘由了。

OK,但这里我们再回过头来看看配置就知道为啥不算我们的提交了:

因为这里配置的是原作者的 GitHub 邮箱,所以这次提交当然就会算作原作者的了。

那怎么才能让我们的绿呢?那把邮箱改成我们自己的就好了,比如我的就修改为了这样子:

name: cion:push:branches:- masterschedule:- cron: "0 0 * * *"jobs:autogreen:runs-on: ubuntu-lateststeps:- name: Clone repositoryuses: actions/checkout@v2- name: Auto greenrun: |git config --local user.email "cqc@cuiqingcai.com"git config --local user.name "Germey"git remote set-url origin https://${{ github.actor }}:${{ secrets.GITHUB_TOKEN }}@github.com/${{ github.repository }}git pull --rebasegit commit --allow-empty -m "a commit a day keeps your girlfriend away"git push

直接在 GitHub 网页上点击修改,修改好了保存就行了。

修改完了之后我们就自动有了一次 commit,接着 Actions 还会自动触发一次 commit,最后结果如图所示:

可以看到,最后这次 commit 已经变成我自己了。

以后,我每天都可以自动绿了。

(这话怎么听着这么奇怪?

福利

最后,原作者还预留了一个定时任务,可以使得你想绿就绿,不仅可以让你每天都绿,还能让你每小时都绿,每分钟都能绿。

想绿就绿,其乐无穷。

绿的方式很简单,套用原作者的介绍了,修改 yml 文件的定时配置就好了:

计划任务语法有 5 个字段,中间用空格分隔,每个字段代表一个时间单位。

┌───────────── 分钟 (0 - 59)
│ ┌───────────── 小时 (0 - 23)
│ │ ┌───────────── 日 (1 - 31)
│ │ │ ┌───────────── 月 (1 - 12 或 JAN-DEC)
│ │ │ │ ┌───────────── 星期 (0 - 6 或 SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

每个时间字段的含义:

符号描述举例
*任意值* * * * * 每天每小时每分钟
,值分隔符1,3,4,7 * * * * 每小时的 1 3 4 7 分钟
-范围1-6 * * * * 每小时的 1-6 分钟
/*/15 * * * * 每隔 15 分钟

比如修改为 0 * * * * ,你就能做到每小时都绿了,修改为 * * * * * 你就能每分钟都绿了,真舒服啊!

注:由于 GitHub Actions 的限制,如果设置为 * * * * * 实际的执行频率为每 5 分执行一次,也就是每 5 分钟绿一次,也还不错嘛~

作者:崔庆才丨静觅

隐形字

在这些地方分享自己的一些经验、想法和见解。

好文和朋友一起看~

这篇关于怎样让你的 GitHub 365 天都保持全绿?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/991841

相关文章

高并发环境中保持幂等性

在高并发环境中保持幂等性是一项重要的挑战。幂等性指的是无论操作执行多少次,其效果都是相同的。确保操作的幂等性可以避免重复执行带来的副作用。以下是一些保持幂等性的常用方法: 唯一标识符: 请求唯一标识:在每次请求中引入唯一标识符(如 UUID 或者生成的唯一 ID),在处理请求时,系统可以检查这个标识符是否已经处理过,如果是,则忽略重复请求。幂等键(Idempotency Key):客户端在每次

如何提高 GitHub 的下载速度

如何提高 GitHub 的下载速度 文章目录 如何提高 GitHub 的下载速度1. 注册账号2. 准备好链接3. 创建仓库4. 在码云上下载代码5. 仓库更新了怎么办 一般来说,国内的朋友从 GitHub 上面下载代码,速度最大是 20KB/s,这种龟速,谁能忍受呢? 本文介绍一种方法——利用“码云”,可以大大提高下载速度,亲测有效。 1. 注册账号 去“码云”注册一

Github连接方式

打开Linux中git的配置文件: /home/username/git/MyRepository/.git/config [core]repositoryformatversion = 0filemode = truebare = falselogallrefupdates = true[remote "origin"]fetch = +refs/heads/*:refs/remot

GitHub每周最火火火项目(9.2-9.8)

项目名称:polarsource / polar 项目介绍:polar 是一个开源项目,它是 Lemon Squeezy 的替代方案,并且具有更具优势的价格。该项目的目标是为开发者提供一种更好的选择,让他们能够在追求自己的热情和兴趣的同时,通过编码获得相应的报酬。通过使用 polar,开发者可以享受到更实惠的价格,同时也能够更自由地发挥自己的创造力和技能。 项目地址:https://github.

LabVIEW程序员是怎样成长为大佬

成为一名LabVIEW编程领域的“大佬”需要时间、实践、学习和解决复杂问题的经验。尽管LabVIEW作为一种图形化编程语言在初期可能相对容易上手,但要真正成为精通者,需要在多个层面上深入理解。以下是LabVIEW程序员如何逐步成长为“大佬”的路径: 1. 打好基础 LabVIEW的大佬们通常在初期会打下非常坚实的基础,理解LabVIEW编程的核心概念,包括: 数据流编程模型:Lab

十四、我们应当怎样做需求分析:子用例与扩展用例

用例模型作为UML中4+1视图中非常重要的一员,非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例,又体现了面向对象设计中的复用性。现在

十三、我们应当怎样做需求分析:查询报表分析

在我以往的用例分析中,使用这样格式的用例模式,对于大多数业务操作流程来说是得心应手的,但对于有些功能来说总感觉不对劲。感觉不对劲的,就是那些查询、汇总与报表功能。对于这部分功能,需要我们描述的不是什么操作流程,而更重要的是那些数据项、数据来源、报表格式、数据链接,以及使用者、使用频率的说明。而这些,在以往的用例说明格式中统统都没有,怎么办呢?俗话说“东西是死的人是活的”,把我们的用例格式改改吧。

九、我们应当怎样做需求分析:功能角色分析与用例图

在我们进行一系列需求调研工作的同时,我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司,我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时,我们应当首先将上次需求分析的结果与客户进行确认,同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。  但是,当我们经

八、我们应当怎样做需求调研:需求捕获(下)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

七、我们应当怎样做需求调研:需求捕获(上)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整