GitHub Desktopの使い方｜画面とターミナルの分担を決める

github desktop 使い方で調べて出てくる解説は、インストールとクローンの画面まででいったん終わっているものが多くあります。ところが実務で手が止まるのはその先です。どの操作を画面で行い、どの操作をターミナルに任せるのか、そして間違えたときにどこから戻すのか。この記事では、公式ドキュメントに書かれている機能の範囲を確かめたうえで、画面とコマンドの分担をどう決めるかを整理します。初心者が最初に覚える手順と、慣れたあとに残る判断を分けて扱います。

GitHub Desktopが受け持っている範囲

まず道具の位置を確かめます。GitHub Desktopについての公式の説明では、GitHub Desktopは GitHub やその他の Git ホスティングサービスでホストされるファイルを操作するのに役立つ無料のオープンソースアプリケーションです。提供されているのは Windows と macOS で、Linux版はありません。動かすには64ビットのオペレーティングシステムが必要で、Macの対応はmacOS 12.0以降とされています。

ここで押さえておきたいのは、Git本体を置き換える道具ではないという点です。公式が一般的な流れとして挙げているのは、GitHub Desktopでリポジトリを手元へダウンロードして新しいブランチを作り、Visual Studio Codeなどのエディタでコードを変更し、GitHub Desktopに戻ってコミットしてプッシュする、という3段構えです。編集はエディタ、履歴の操作はこのアプリ、という分担が最初から前提になっています。

もう1つの前提は、GitHub側の機能との距離です。コミットやブランチはGitの機能ですが、プルリクエスト、レビュー、チェックの実行結果はGitの外側にあります。GitHub Desktopはその外側にも手が届くように作られていて、別の資格情報マネージャーを用意しなくても認証が済み、ブラウザを開かずにプルリクエストをチェックアウトしてチェックを実行できると公式に書かれています。つまりこのアプリの価値は、Gitの操作を絵にしたことよりも、GitHubの機能を手元の画面に引き寄せたことにあります。

導入のステップと、最初に決めておく設定

インストールと認証が済んだら、その日のうちに決めておいたほうがよい設定が4つあります。手順の記事ではあまり強調されませんが、後から直すと履歴が混ざるものが含まれます。

• Gitの構成にある名前とメールアドレス。ここが合っていないと、コミットがGitHub上の別のアカウントに関連付けられます。公式の案内も、間違ったアカウントに紐づいた場合はGitHub Desktopを使ってメールアドレスを更新するよう書いています。
• 既定のエディタ。リポジトリを開くときに呼び出すアプリを指定できます。指定していないと、開くたびに選ぶ手間が残ります。
• 外観の設定。差分の表示に使われる既定のタブサイズは8で、設定ダイアログの外観のペインで変えられます。インデントが2スペースの規約で書かれたコードは、ここを直さないと差分が読みにくくなります。
• 大きなファイルの扱い。Git LFSを使うリポジトリでは、クローンの前に扱いを決めておくほうが安全です。

認証のときに1つ注意点があります。macOSでサインイン後に認証情報のエラーが出る場合、原因はキーチェーンへのアクセスであることが公式のトラブルシューティングに挙げられています。アプリの再インストールから始める前に、キーチェーンのロックと解除を試す順番が示されているため、入り口の失敗で作り直しに走らないほうがよい場面です。

使い方の中心は、コミットに含める範囲の選び方

日々の使い方でいちばん触るのは変更タブです。エディタで保存した内容がそのまま一覧に並び、削除されたファイルは赤、変更されたファイルは黄色、追加されたファイルは緑のアイコンで区別されます。チェックボックスで含めるファイルを選び、キーボードならSpacebarかEnterで切り替えられます。

この画面の本当の価値は、ファイル単位より細かく選べることです。1つのファイルに複数の変更があるとき、その一部だけを含める部分的なコミットを作れます。仕組みは単純で、青く強調されている行がコミットに含まれ、クリックして青を消した行は含まれません。公式はこの機能の狙いを、改行の変更をコードや構文の変更から区別するなど、個別で意味のあるコミットを作れるようにすることだと説明しています。ターミナルの git add -p に相当する操作を、差分を見ながらマウスで行える形です。

差分の見せ方も選べます。表示方法は1列に並べるUnifiedと、左に古い内容、右に新しい内容を置くSplitの2種類です。空白の変更を隠す指定を使えば、インデントの入れ替えに埋もれた実質的な変更だけを追えます。前後の数行しか見えないときは行番号の上下にある矢印で広げられ、右クリックからファイル全体の表示に切り替えることもできます。

つまり、載せる範囲を決める作業に関しては画面のほうが速く、正確です。コマンドの構文を思い出す時間がゼロになり、選んだ結果がそのまま目に見えます。初心者に画面から勧める解説が多いのは、感覚の問題ではなく、この1点で合理的だからです。

画面が得意なことと、コマンドが得意なこと

一方で、画面だけに寄せると起きるデメリットも知られています。

その他GitHub Desktopばかり使っているとコマンドラインに慣れにくくなる点は、GitHub Desktopを使うデメリットといえます。GitHubについてより深く理解したい場合は、各種コマンドの使い方についても、学習しておくとよいでしょう。 出典: kagoya.jp

この指摘を「だからコマンドを覚えるべき」で終わらせると、判断の基準が残りません。操作ごとに速いほうを選ぶ、という形にしたほうが実務では扱いやすくなります。

操作	速いのはどちらか	理由
差分を見ながら載せる範囲を選ぶ	画面	行単位の選択が目で確認できる
プルリクエストのチェック結果を見る	画面	ブラウザを開かずに確認できる
直前のコミットの作り直し	どちらでも	修正の機能が画面側にもある
数個前の履歴の並べ替えや吸収	コマンド	対話的な指定のほうが小回りが利く
同じ操作を複数のリポジトリへ	コマンド	繰り返しを書ける
手順の自動化や検査の組み込み	コマンド	画面の操作は記録に残せない

比較の軸をこの形にしておくと、どちらの道具を捨てるかという話にならずに済みます。GitHub Desktopの側にも、コミットの修正、打ち消し、チェリーピック、並べ替え、まとめる操作、特定のコミットへのリセットまで用意されています。用意されていない操作に出会ったときだけターミナルへ渡す、という順番が現実的です。

手が止まりやすい場面と、戻し方

使い方の記事で薄くなりがちなのが、失敗したあとの話です。よく当たる4つを押さえておくと、作り直しに走る回数が減ります。

変更を捨てたいときは、変更の破棄を使います。ここで安心できるのは、破棄した変更がゴミ箱の中の日付つきのファイルに保存される点です。ゴミ箱を空にするまでは戻せるため、間違って捨てた直後であれば救えます。

作業を中断したいだけなら、変更の一時退避を使います。退避した内容は変更タブのStashed Changesから戻せます。コミットとして無理に記録を残す必要はありません。

コミットが弾かれる場合は、リポジトリ側の規則が原因かもしれません。管理者はブランチのルールセットで、コミットへの署名や、コミットメッセージの先頭でのイシュー番号の参照を要求できます。規則に従っていないとき、GitHub Desktopは警告を出してコミットを止めます。手元の設定が壊れたわけではないため、メッセージの文面を先に読む場面です。

検査の仕組みが噛んでいることもあります。GitHub Desktopは、構成済みのシェル環境でGitフックを実行します。公式の説明では、nvmやrbenvのようなバージョンマネージャーが入れた道具に依存するフック、.bash_profile や .zshrc に依存するフックも正しく動き、出力は色や書式を保ったまま画面にそのまま表示されます。どうしても先に進めたいときはコミットフックのバイパスを選べますが、これはコマンドラインの git commit --no-verify と同じ意味で、チームが頼っている品質と安全性の検査を飛ばす指定です。常用するものではありません。

ターミナルへ渡す手順と、ブランチの持ち方

画面とコマンドを行き来するなら、入り口を作っておくと早くなります。メニューバーのGitHub Desktopメニューからコマンドラインツールのインストールを選ぶと、ターミナルで github が使えるようになります。引数なしなら最後に開いたリポジトリ、パスを付ければそのリポジトリ、リポジトリの中でドットを付ければその場所が開きます。

cd /path/to/repo
github .

ブランチの持ち方にも新しい選択肢が入りました。ワークツリーを使うと、同じリポジトリの複数のブランチを同時にチェックアウトできます。それぞれのブランチは手元の別のディレクトリに置かれるため、作りかけの変更を退避したり無理にコミットしたりせずに、別のブランチでプルリクエストを確認したり修正を作ったりできます。GitHub Desktopは作成、切り替え、名前の変更、削除に対応しており、リンクされたワークツリーが1つ以上あるときだけツールバーにWorktreeのドロップダウンが出ます。

便利さの裏返しとして、手元のディレクトリは増えます。同じ名前のファイルが別の場所に並び、ターミナルで開いている場所と画面で見ている場所が食い違う状況が生まれます。使い方の記事はここで終わりますが、実際の作業が詰まるのはこの先です。

窓の数を数えると、詰まっている場所が見える

1つの変更を仕上げるまでに、いくつの窓を使っているかを数えてみると、道具の選び方が変わります。エディタ、GitHub Desktop、ターミナル、リポジトリのフォルダ、仕様を確認するブラウザで5つになることは珍しくありません。コミットの粒度が荒くなる原因の多くは知識の不足ではなく、行き来の途中で区切りを作る機会を失うことです。

この観点で効くのは、窓を1つ減らすことです。フォルダの一覧とシェルが同じ場所にあれば、変更したファイルを見ながらコマンドを打ち、そのままGitHub Desktopへ渡す動作が続けて行えます。フォルダとターミナルとAIが同じ窓にある形を選ぶと、ワークツリーでディレクトリが増えても場所を見失いにくくなります。ファイル管理の側で何ができるのかはできることにまとまっています。

他の道具と何が違うのかを先に知りたい場合は他のファイル管理との比較が近い内容です。手元の機械を離れたあとに続きを確かめたい場面についてはiPhone・iPadから続きをで扱っています。条件を確かめてから決めたいときは料金とよくある質問を先に見ておくと判断が早くなります。

使い方の結論は短く言えます。載せる範囲を選ぶ操作は画面に任せ、履歴の作り直しと繰り返しの作業はコマンドに任せる。そして、その2つを行き来する距離を短くする。覚えるべき手順の数は、この分担を決めた時点で減ります。