ターミナル

コードを書いているのはエディターとターミナルなのに、プルリクエストを出すときだけブラウザに移る。タブを探し、リポジトリのページを開き、「Compare & pull request」のボタンを押し、タイトルと説明を書き直し、レビューをお願いする相手を選ぶ。一つひとつは数十秒の作業でも、1日に何度も繰り返すと、そのたびに頭の中で組み立てていた続きが途切れてしまう。私が気になっていたのは、時間そのものより、この途切れのほうだった。 GitHub CLI、コマンド名で言えば gh は、GitHub が公式に配布しているコマンドラインの道具だ。git が手元のリポジトリと遠くのリポジトリのあいだで履歴をやり取りする道具だとすれば、gh はその外側にある GitHub 独自の仕組み、つまりプルリクエスト、イシュー、Actions の実行結果、リリースといったものをターミナルから扱うための道具になる。git の代わりではなく、git の隣に置いて使う。 この記事では、朝にブランチを切ってプルリクエストを出し、昼に CI の結果を待ち、午後にレビューをやり取りして、夕方にマージするまでの一日を、gh のコマンドだけでたどっていく。最後に、毎日使うための短縮の設定と、それでもブラウザを開いたほうが早い場面もまとめておく。 準備はインストールとログインの2つだけ エディターの隣にターミナルを置いておけば、プルリクエストの操作もそこで済むPhoto: Wikideas1 / CC0 インストールは、Windows なら winget install --id GitHub.cli、macOS なら brew install gh の1行で終わる。Linux でも主要なディストリビューション向けのパッケージが用意されている。入れ終わったら gh --version で版を確かめておく。gh は数週間おきに新しい版が出るので、手順の説明と手元の動きが違うと感じたら、まず版を新しくするのが近道だと思う。 次にログインする。gh auth login を実行すると、どの GitHub につなぐか、git の通信に HTTPS と SSH のどちらを使うかを順に聞かれる。認証の方法は、ブラウザでの承認を選ぶのが手軽だ。ターミナルに8文字の確認コードが表示され、ブラウザで GitHub の承認画面を開いてそのコードを入れると、ログインが完了する。ブラウザを使うのはこの一度だけで、受け取った認証情報は OS の資格情報の保管場所にしまわれる。 ログインできたかどうかは gh auth status で確かめられる。どのアカウントで、どこに認証情報が置かれているかが表示される。あわせて gh auth setup-git を一度実行しておくと、git の push や pull でも gh の認証情報が使われるようになり、パスワードやトークンを毎回聞かれることがなくなる。サーバーや自動化の仕組みの中で使うときは、ログインの代わりに環境変数 GH_TOKEN にトークンを入れておけば、gh はそれを読んで動く。 ...