2015年から行なっている Write Code Every Day というか、GitHub に草を生やす活動は、2019 年から JST では途切れることなく続いている。去年 2022 年には rubocop org だけでも毎日草が生えるようにしようとしていて達成していた。
毎年同じ草の生やし方をしても面白くないので、近年はそんな感じで縛りルールを作って行なっている。
今年 2023 年は rubocop/rubocop リポジトリ単独だけでも毎日草を生やそうというか、rubocop/rubocop リポジトリに 365 日コミットを入れてみようと進めて達成した。365 日のコミットに対したもうけた縛りは以下の2つ。
- コミットログのタイムスタンプを 365 日入れる
- GitHub 上の commits で 365 日表示されるようにする
前者は git log に準じた日付を入れるだけなので問題ない。ひとつだけ気にしないといけないのは、マージされるか微妙なプルリクエストを出すようなことがある場合には、それとは別に確実に master に入れることができる同じ日のコミットを設けておくということ。保険重要。
後者はちょっとクセがある。GitHub の commits に表示されるものは、git log のタイムスタンプに準じるとは限らない。ちょっと複雑なので条件を以下に書いておく。
- マージコミットを作るケースでは、マージ元の PR に紐づくコミットが commit された日付に準じる。これの何に気を配るケースがあるかというと、対応すべきレビューコメントがついて修正 squash の後に force-with-lease した際には、その日付が commits に残る。レビューコメントもそうだし、master ブランチとのコンフリクトが発生してその解消が必要な際も同様。つまり
git logのタイムスタンプが commits に表示されるとは限らない点に注意が必要 - squash merge のケースでは、squash merge した日付として commits には表示される。つまり 1月1日にコミットして PR を開いたとして、1月3日に squash merge されると 1月3日の commits として表示される
後者も即日マージされれば気にすることはないけれど、レビューを受けた方が良いときは master 直ではなくプルリクエストにしているわけで、そういったケースでは保険を気に掛ける必要がある。
こんな感じでいくつか気を配らないといけないポイントがあるので、マージコミットも 365 日のコミットに含めることを OK とした。マージコミットは git log ならびに GitHub の commits のいずれにもそのタイムスタンプで反映されるのでたいへん便利。
GitHub 上の見た目はタイムゾーンに依存するが、そこは JST でのみクリアできれば良いものとしたのも難易度を易しい方に倒した点としてある。
という GitHub 遊びを 2023 は行なっていた。地球上に同じような縛りルールで遊んでいる人が他にいるかわからないけれど GitHub 遊びの参考までに。
