2019-04-13

コードを書かずに GitHub の草を生やしたいなら、GitHub Issues でタスク管理する

転職活動の際に、GitHub アカウントの提示を求められたりする機会が増えているみたい。自分も実際、転職活動中には GitHub アカウントを教えてと云われて、見せたことがある。

僕の場合は、転職活動当時は「ライブラリを試しに使ってみた」リポジトリを立てていたり、簡単なスクリプトを配布するテイでまとめていたりして、それなりに活動している風の Contributions に仕上げてあった。レベルの低いコードばかりであったが、ココにはウソはなかったし、リアルな「これからガンガン勉強していきます！」感は伝わっていたのではないかと思う。

その頃の僕は、前職の仕事をのらりくらりとかわして定時退社し、夜通しプログラミングしたりしていた。PC の持ち込みは禁止されていた職場だったが、こっそり MacBookPro を持ち込んで出社していて、昼休みの間に近所のカフェで React の勉強をしたりもしていた。自宅と職場が近かったし、男の一人暮らしだったので、他の家事なんかも全て犠牲にしてプログラミングに費やしていたから、GitHub Contributions は自然と増やせたのだ。

しかし、状況の異なる皆さんの中には、そうそうコードでの成果ばかり見せる時間がない人も多いと思う。PC 環境もネット環境も違うだろうから、みんながみんな、コーディングだけで GitHub Contributions を充実させるのは難しいと思う。

そこで、今回僕が紹介するのは、GitHub Issues でタスク管理することで GitHub Contributions の草を増やすという方法だ。

参考 : Viewing contributions on your profile - GitHub Help

コチラの公式ガイドによると、Contributions にカウントされる内容はこうしたものだそうだ。

Committing to a repository's default branch or gh-pages branch

Opening an issue

Proposing a pull request

Submitting a pull request review

Co-authoring commits in a repository's default branch or gh-pages branch

1つ目が、普段のコミットで草が付く原理。注意すべきは、リポジトリのデフォルトブランチか gh-pages ブランチへのコミットが対象なので、Feature ブランチを作る運用だと、マージするまで草が生えない。僕の場合は、「ライブラリの勉強中リポジトリ」みたいなモノは全て master ブランチに Push していたので、ガンガン草が生えていた。

2つ目が、今回の要旨。Issue を作成 (Open) すると、Contributions としてカウントされるのだ。この Issue は自分が作ったリポジトリに自分で Issue を上げてもカウントされるのが特徴。

そこで、自分のタスク管理用のリポジトリを作り、日々のタスクを Issue として書き出すのだ。自分の場合は、「Neos21」という名前のリポジトリをタスク管理用にしていて、「このブログにこのネタ書きたい」とか、「このライブラリの使用感を確かめたい」とか、そんな課題・ToDo を Issue として上げている。

コードは書いていないし、まだ「やりたいこと」を書いたまでで実現もしていないのに、Issue を Open するだけで草が生える。

最近、GitHub Issue ページのデザインがスマホ向けにも調整されたので、スマホからの Open、Close なんかも楽チン。ラベル付けに難があるものの、とりあえず書くだけなら問題ない。

ToDo を書き出すことは自分のタスク整理のためにも重要なことだし、日々の ToDo 管理を GitHub Issue で行うだけで草が生やせるなら儲けものである。

コードを更新する場合は、この方法でもっと草が生やせる。

まず、タスク管理用リポジトリで「○○リポジトリに□□機能を追加する」というタスクを上げておく。続いて、「○○リポジトリ」側にも同じような Issue を作る。

そしてコードは Feature ブランチを切って更新し、プルリクを作る。このとき、プルリクのタイトルで「○○リポジトリ」に作った Issue の番号を入れておくと、プルリクをセルフでマージした時に、Issue もクローズしてくれる。

プルリクのオープンや master ブランチへのコミットがそれぞれ Contributions としてカウントされるので、少し濃い草を生やせるのだ。

本当に草を生やしたいだけなら、拙作の gh-contributions というシェルスクリプトでも実現できるが、Contributions の中身を見られるとフェイクだとバレる。

参考 : GitHub - Neos21/gh-contributions: GitHub の草を生やすシェルスクリプト

タスク管理として Issue を使っています、草が濃いところは実際にコードをマージしたところです、一人でやってますがプルリクとかも使いこなしててチーム開発も大丈夫です、という感じで、GitHub を見せたときのアピールポイントが増やせるので、コードをガリガリ書く余力が作れない時は特に、こうした手法も使ってみてはいかがだろうか。