GitHubで個人的によく使っている機能まとめ
🍏が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+assignee%3A@me+user%3Aorg-name
(追記 2022/09/12) 検索修飾子には assignee:@me の様にログインしている自身を指定するマクロ的なものもあります。他の検索構文なども調べて各自のワークスタイルに合わせた検索条件を使いましょう。
検索構文を理解する - GitHub Docs https://docs.github.com/ja/search-github/getting-started-with-searching-on-github/understanding-the-search-syntax
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を使いましょう。
🙅: https://github.com/mstssk/rollup-plugin-cleandir/blob/master/index.ts#L4
🙆: https://github.com/mstssk/rollup-plugin-cleandir/blob/04506eb3e1ac2336a4e7f35dc1bfe0be622ee0e7/index.ts#L4
タグを使う方法もあります。
Blameしながら親コミットをたどる
Blameの画面で、そのコミットが適用される前のコミットに移動するリンクがある。
どういう経緯で変更が行われたのか参照するときに便利。
ただし、コミットログが雑にされている場合もあり、どちらかというと次のコミットからPRをたどる方法の方がよく使う。
コミットが所属するPRを参照する
各コミットのページには、そのコミットが含まれているブランチやタグ、PRへのリンクがある。
このリンクからPRを見に行く事で、どういう目的で手が加えられたか参照する。
🍏が所属するプロジェクトでは、コミットログについてはあまり口を出さないが、すくなくともPRではどういう目的の実装なのか書いていたり関連するIssue Trackerへのリンクが貼られているかもレビュー時にチェックすることで、最低限は実装の由来を将来辿れるようにしている事が多い。
Organizationごとに別のメールアドレスに通知する
仕事用とプライベートとでGitHubアカウントを分けていない場合、仕事のOrganizationのリポジトリに関連する通知がプライベートのメールアドレスに届いても困ります。
GitHubは所属しているOrganization別に通知先メールアドレスを切り替える事ができます。
仕事用のメールアドレスをGitHubアカウントに追加して、会社のOrganizationだけ仕事用のメールアドレスに切り替えておきましょう。
2FAはアクセストークンをパスワード代わりにするよりSSH keyで
GitHub アカウントを2FAにしておくと、リポジトリにpushする時にパスワードを求められたりしてびっくりしたりしつつアクセストークンを設定したりしたものですが、今はマシン別にSSHキーを準備して済ませています。
リポジトリをcloneするときもSSH形式で行っておくとスムーズです。
トークン使う方法でも同じくらいシンプルにできるかもしれませんが、自分はSSH keyで済ませるほうがしっくりきたので。
Security Alerts
依存関係の脆弱性アラートとDependabotの自動バージョンアップPR作成は有効にしておきましょう。
依存の依存の依存パッケージに脆弱性アラートが上がったときなんかは複雑すぎてDependabotがエラーになってたりしますが。
GitHubリポジトリのwatch
- 特定のissue,PRだけをwatchもできる
- 使っているOSSの特定のバグを踏んだ時、その対応をしているissueをwatchしてpatchが公開されたらすぐ対応できるようにとか
- カスタムwatchでリリースだけチェックするというのもあり
リポジトリ内のファイル名で検索
あれ？あそこどうなってたっけ？と思った時に手元でIDE立ち上げるより、GitHubリポジトリ上でファイル名で検索したほうが早いこともあります。
「Go to file」ボタンでもいいですが、 t でショートカット起動を覚えておくと楽です。
他のショートカットなどはこちら。
Schedules reminders
https://github.com/settings/reminders/
SlackとGitHubを連携させておくと、チームのチャンネルに通知したりもできますが、個人用にスケジュールを決めたリマインダーも設定できます。
🍏の場合は、毎日特定の時間にチームのチャンネルにレビュー待ちなどの通知がくるのとは別に、レビュー依頼が出されたらリアルタイムで通知してくれるようにもしています。
PRのレビュー時の便利機能
☑️ Viewed
レビュー対象のファイルが多い場合に特に使います。
☑するとそのファイルが折りたたまれてくれるので、他のファイルの確認に集中できます。
Hide whitespace changes
空白のdiffを無視して表示してくれます。
インデントが変わってるだけなど、不必要なdiffを無視してレビューできます。
昔から隠し機能としてURLに ?w=1 を付けるとwhitespaceのignoreができたのですが、あるタイミングでちゃんと機能としてUIに搭載されました。
Suggested changes
レビューで具体例を挙げてこう直すといいよ、と伝える場合に使える機能です。
ちょっとしたtypoの指摘などにも使えます。
レビュイーはそのまま取り込むことも出来ます。
あくまでPRとして出されたdiffの中でしか使えないので、周辺のコードも含んだ大きめの変更指摘なんかには使えません。
GitHub外の機能
Octotree
現在開いているリポジトリ・ブランチの内容をツリー表示してくれます。
特定のファイルを見たいわけでなく、上からたどって探したいときなんかに重宝します。
Discussion