Viibarのエンジニアの id:mstssk です。

Viibarの開発部では、発表者を持ち回りにして好き勝手なことを発表しあう社内勉強会をやっています。

発表内容は本当に好き勝手でよく、初めて発表担当が回ってきたときは延々Splatoonの話をしたりしたんですが、今回は「もっとみんなGitHub使いこなそうぜ」という内容にしました。

※この記事はZennにも投稿しています。

id:mstssk がGitHubを使うにあたって日常的に使っている機能などなどです。社内勉強会のために書き出したものをちょっとだけ清書して投稿しています。

定期的に確認するページ

ページ	URL
通知	https://github.com/notifications
レビュー依頼	https://github.com/pulls/review-requested
自分が担当のIssue,PR	https://github.com/pulls/assigned
自分へのmention	https://github.com/pulls/mentioned

ただし、仕事では特定のOrganizationだけにスコープを絞りたいので、次のようなURLをブックマークして使ってます。

https://github.com/pulls?q=is%3Aopen+user%3AViibar+assignee%3Amstssk

Pull Request の Draft 機能

PRをDraftにしておくことで作業中であることを明確にできます。 Draft機能ができる前はPRのタイトルに [WIP] と入れたりしていました。

ただし、DraftのPRでもレビュアー設定をしたら、レビュアー設定された人に通知が飛びます。不必要にノイズを飛ばさないよう、レビューできる状態になってからレビュアーは設定しましょう。

自分をアサインする

機能というか習慣です。

https://github.com/pulls/assigned のページを活用して自分が現在携わっているものを一覧しやすくするためにも、作業中のIssueやPRには基本的にちゃんと自分をアサインするべきです。

アサインするのを忘れがちなのなら、 https://github.com/apps/auto-assign のような自動でアサインするBotを使ってもいいです。

PRをレビュー依頼を出す前にrebaseする

これも習慣やお作法の類です。トピックブランチで作業している間にベースブランチが進んでいるとかはよくある話なので、動作確認してレビュー依頼出す直前にrebaseしておきましょう。

$ git fetch
$ git rebase origin/master topic
$ git push origin topic --force-with-lease

Permalink

GitHub リポジトリ上のファイルの特定の箇所を指し示す時、そのブランチの変更に関わらず一定になるPermalinkを使いましょう。

タグの場合ならこういうURL https://github.com/mstssk/rollup-plugin-cleandir/blob/v1.0.0/index.ts#L4

Blameしながら親コミットをたどる

Blameの画面で、そのコミットが適用される前のコミットに移動するリンクがあります。どういう経緯で変更が行われたのか参照するときに便利です。

ただし、コミットログが雑にされている場合もあり、どちらかというと次のコミットからPRをたどる方法の方をよく使ったりします。

コミットが所属するPRを参照する

各コミットのページには、そのコミットが含まれているブランチやタグ、PRへのリンクがあります。このリンクからPRを見に行く事で、どういう目的で手が加えられたか参照できます。私が所属するプロジェクトでは、コミットログについてはあまり口を出さないが、すくなくともPRではどういう目的の実装なのか書いていたり関連するIssue Trackerへのリンクが貼られているかもレビュー時にチェックすることで、最低限は実装の由来を将来辿れるようにしている事が多いです。