こんにちは

4月から入社、Web開発共に2年目になるソーイ株式会社の村上です。

GitHub Desktopは、直感的なUIで差分（Diff）も確認しやすく、個人開発から業務まで幅広く支えてくれる非常に強力なツールです。しかし、その「ボタン一つで何でもできてしまう手軽さ」は、時にGit初心者にとっての落とし穴になります。

本来、コマンドライン（CLI）で操作する場合は、正しいコマンドを調べ、その意味を理解して打ち込まない限り動作しません。この「調べるステップ」が、無知による事故を防ぐフィルターとして機能します。

一方で、GUIは仕組みを理解していなくても「なんとなく」で操作が完結してしまいます。

「とりあえずFetchしたから最新だよね？（中身は更新されていない）」

「ブランチを変えたら作業内容が消えた！（実は自動でStashされているだけ）」

「気づかないうちに別ブランチの変更をマージしていた」

こうした 暗黙の挙動 によるミスを減らすには、UIのボタンを押したとき、裏側でどのGitコマンドが動いているのか を一致させることが近道です。

本記事は、GitHub Desktopの操作とGitコマンドの対応関係を整理し、ツールに「使われる」のではなく、仕組みを理解して「使いこなす」ための備忘録・第1弾です。

この記事内のUIはWindows版をベースにしていますが、Mac版でも配置が異なるだけで、同様の操作が可能です。

この記事のターゲット層

この記事は、以下のような方に向けて書いています。

GitHub Desktop を「なんとなく」で使っている人

Git コマンドに苦手意識があり、GUI でしか操作したことがない人

Gitの知識はほとんどないが、Gitを用いた開発を行ってみたい人

この記事で分かること

本記事では、GitHub Desktopの直感的なUI操作が、内部でどのようなGitコマンドとして実行されているのかを対照形式で解説します。

基本操作の裏側（Clone / Commit / Push / Fetch）
一時退避や変更破棄（Stash / Discard）
ブランチ管理とマージの挙動
初心者が陥りやすい「GUIの落とし穴」と対策

GitHub Desktop 操作 vs Gitコマンド対応一覧

本記事で解説する、主要な操作と内部コマンドの対応表です。各操作の役割と影響範囲を整理しました。

GitHub Desktopの操作	実行される主なコマンド	動作の役割・エンジニアの意図
Clone	`git clone`	リポジトリを自分のPCに丸ごとコピーして同期を開始する
Commit	`git add` + `git commit`	選択したファイルの変更を、ローカルの歴史として記録する
Push	`git push`	ローカルで積み上げたコミットをGitHubサーバーへ送信する
Fetch	`git fetch`	リモートに新しい更新があるか情報だけを確認しに行く
Pull	`git pull`	リモートの最新の変更を、自分の作業ファイルに反映させる
New Branch	`git switch -c`	今の状態をベースに、安全な作業用の「脇道」を作成して移動する
Publish Branch	`git push -u`	ローカルで作った新ブランチを、初めてサーバーへ公開・同期する
Merge	`git merge`	他のブランチ（機能追加など）の変更を今のブランチに統合する
Stash	`git stash push`	書きかけの変更を一旦退避し、作業場を綺麗にする
Restore (Stash)	`git stash pop`	隠し場所に置いていた作業内容を取り出し、今のファイルに復元する
Discard Changes	`git restore`	【注意】変更をすべて捨てて、直前のコミット状態まで強制的に戻す
Discard Lines	`git checkout -p`	【注意】特定の行の変更だけを、部分的にコミット前の状態に差し戻す
Revert	`git revert`	過去のコミットを「打ち消すためのコミット」を新しく作成する

UIと動作するコマンド

1. Clone（リポジトリの複製）

GitHub上にあるプロジェクトを、自分のPCで編集できるように丸ごとコピーしてくる操作です。

UI操作

GitHub Desktopでの操作: File > Clone Repository からリポジトリを選択。
またはCtrl + Shift + O
表示されたウィンドウ内で対象のリポジトリを選択し、Cloneを押下。

コマンド

Clone

git clone https://github.com/username/repository.git

単にファイルをダウンロードするだけでなく、「このフォルダはGitHub上のあのリポジトリと繋がっていますよ」という 接続情報（origin） を自動で設定します。これにより、後で紹介するPushやPullが可能な状態になります。

2. Commit（変更の記録）

ファイルに加えた変更を、リポジトリの変更履歴として保存する操作です。

UI操作

画面左側の Changes タブで変更ファイルにチェックを入れ、左下の Summary（必須）と Description（任意）を入力して Commit to [branch-name] をクリック。

コマンド

Commit

# 変更されたファイルをステージング（保存対象に含める）
git add [file-name] 

# コミットの実行（変更履歴として保存）
git commit -m "Summary" -m "Description"

コマンド操作ではどのファイルを保存するか選ぶ（add）と保存する（commit）の2段階が必要ですが、UIではチェックボックスがその役割を果たしています。「コミットした＝自分のPC内の歴史に刻まれた」 状態ですが、まだGitHub（サーバー）には反映されていない点に注意が必要です。

3. Push（リモートへの送信）

自分のPCで記録したコミットを、GitHub上のサーバーへ送り届けて同期させる操作です。
ここで初めて全員がブランチを確認した際に差分が確認できます。

UI操作

Commit操作後、画面上部の Push origin ボタンをクリック。
またはCtrl+Pを入力。

コマンド

Push

git push origin [branch-name]

ローカルにある「最新の歴史」をサーバーへアップロードします。Pushして初めて、他のメンバーがあなたの変更を見たり取り込んだりできるようになります。ボタンが Publish branch になっている場合は、そのブランチ自体を初めてサーバー上に作成します。

4. Fetch（最新情報の取得）

リモートリポジトリに 自分の知らない新しい更新があるか 確認しに行く操作です。

UI操作

画面上部の Fetch origin ボタンをクリック。

コマンド

Fetch

git fetch origin

ここが最大の勘違いポイントです。Fetchはあくまで 情報の確認 であり、自分の手元のファイルは1ミリも書き換えられません。誰かが更新したらしい という情報を取ってくるだけなので、実際に中身を最新にするには、この後の Pull（Merge） が必要です。
自身も初期の頃に経験しましたが、Fetchを行わないまま作業を進めてしまうとコンフリクトの元になります。こまめに実行することをおすすめします。

5. Pull（最新の反映）

GitHub上の最新の変更を、自分のローカルブランチに取り込んで合流させる操作です。

UI操作

Fetch 実行後、ボタンが Pull origin（または Pull origin with rebase）に変わったのを確認してクリック。

コマンド

Pull

# 内部的には Fetch + Merge が動いている
git pull origin [branch-name]

Fetchで取得した最新の変更履歴を、今の自分の作業ファイルに実際に合流（merge）させます。
「Fetchしたのにコードが変わらない！」という初心者によくある混乱は、このPullを忘れていることが原因です。 UIが Pull を促す表示に変わったら、今から中身を書き換えるぞという意識を持ってボタンを押す必要があります。

6. New Branch（ブランチの新規作成）

メインの道（main）を汚さずに、新しい機能開発や実験を行うための「脇道」を作る操作です。

UI操作

上部中央の Current Branch をクリックし、New Branch ボタンを押して名前を入力。
表示されるウィンドウでは以下2つのブランチが表示されます。

main（またはデフォルトブランチ）
現在表示しているブランチ

この画面では初期選択がmain（またはデフォルトブランチ）になっています。
現在表示しているブランチから伸ばす場合は選択を変更する必要があります。

コマンド

New Branch

# 指定した分岐元（例: main）から新しいブランチを作成し、そこへ移動する
git switch -c [new-branch-name] main

どの時点の状態をコピーして新しい道を作るかを選んでいます。
基本的には main などの統合ブランチをベースに作成するのが安全ですが、大きな機能を追加する場合は、mainの前に機能名でブランチを作成してクッションとすることで、壊滅的なコード変更を統合ブランチへ含める前に確認できるためおすすめです。

7. Publish Branch（ブランチの公開）

ローカルで作成した新しいブランチを、GitHub上のサーバー（リモート）へ初めて送り出す操作です。

UI操作

New Branch 作成後、画面中央の大きな青いボタン Publish branch をクリック。
または画面上部のPublish branchをクリック。

コマンド

Publish Branch

# リモートに同名のブランチを作成し、自分のPCと同期（追跡設定）させる
git push -u origin [new-branch-name]

自分のPCにしかない新しい作業ラインを、GitHub側にも作成して同期させます。一度この操作を行えば、次からは単なる Push ボタンに変わります。
このボタンを押すまで、GitHub上ではプルリクエストを作成したり、他のメンバーに自分の作業を見せたりすることはできません。

8. Branch Merge（ブランチの統合）

別のブランチで作った変更を、今のブランチに取り込んで一つにまとめる操作です。

UI操作

メニューの Branch > Merge into current branch... を選択（またはCtrl + Shift + M）。

取り込みたいブランチ（source）を選んで Merge をクリック。

競合した場合

この時、差分が競合している場合、警告を表示するマークとともに競合しているファイル数が記載されます。

この状態でCreate a merge commitを取り込むと、
「差分が競合しているけどどちらかの差分を取り込むかあるいはvscodeを開いて修正してね」というポップアップが表示されます。

詳しい解説は中級編で行います。

コマンド

Branch Merge

git merge [other-branch-name]

他の人が作った機能や、自分が別ブランチで進めていた修正を、今の作業場所に合流させます。
変更履歴を一本に束ねる複雑な処理ですが、UIでは視覚的に選ぶだけで完結します。

9. Stash（作業の一時退避）

作業中だけど、急ぎで別のブランチを確認したいという時に、今の書きかけの状態を一時的に 隠し場所に置く操作 です。

UI操作

変更がある状態で別のブランチに切り替えようとした際に表示されるダイアログで Leave my changes on [current-branch] を選択。

またはメニューの Branch > Stash All Changes を実行。
またはCtrl + Shift + S。

コマンド

Stash

# 現在の変更をスタック（隠し場所）に保存
git stash push "GitHub Desktop Stash"

コミットするほどではない書きかけのコードを、安全な領域に一時保存します。
GitHub Desktopはこれを自動で提案してくれますが、隠した場所（Stashリスト） から後述のRestore操作で取り出さない限り、ファイルは消えたように見えるため、初心者が最もパニックになりやすいポイントです。

10. Restore Stash（退避した作業の復元）

Stash（退避）させていた作業内容を、再び現在の作業場に戻す操作です。

UI操作

Stash操作後に表示されるStashed Changesを押下。
表示されたページでRestoreを押下。

コマンド

Restore Stash

# 直近に退避した内容をリストから取り出し、現在のファイルに適用してリストから削除する
git stash pop

GitHub Desktopでは、Stashが存在するブランチに切り替えると、親切に Stashがありますよ とバナーで教えてくれます。
Restoreを押して初めて、以前の書きかけの状態がエディタ上に復活します。
もし不要になった場合は、隣の Discard を押すことで git stash drop（退避内容の完全削除）が行われます。

11. Discard Changes（変更の破棄）

コードが収拾つかなくなったり一部分だけ変更差分を破棄したい場合に最新のコミット時点まで戻す操作です。

UI操作

ファイル単位で破棄したい場合は、Changes タブでファイルを右クリックし、Discard Changes... を選択。

行単位で破棄したい場合は、差分が表示されている部分を右クリックし、表示されるDiscard modified lines...を選択。

コマンド

Discard Changes

# ファイル全体の破棄
git restore [file-path]

# 特定の行（ハンク/パッチ）のみの破棄
git restore -p [file-path]
# (内部的には対話形式で特定の変更箇所を元に戻す処理が走る)

最後にコミットした状態へ強制的に戻します。この操作で消したコードは、 **ゴミ箱にも残らず完全に消滅します。 ** 行単位でのDiscardは非常に便利ですが、誤って必要な行を消すと二度と戻せないため、UIの手軽さに隠れた 危険性 を理解しておく必要があります。

12. Revert（コミットの打ち消し）

「過去に行ったあのコミット（変更）が間違いだったので、取り消したい」という操作です。

UI操作

History タブから対象のコミットを右クリックし、Revert changes in commit を選択。

Revertすると、以下画像のように上書きするCommitが追加されます。

RevertをRevertすると、Reapplyとなり、コミット打ち消しを打ち消し、要は変更が戻ります。

コマンド

Revert

# 指定したコミットの「逆」の変更を行う新しいコミットを作成する
git revert [commit-hash]

Discardと違い、 歴史を消す のではなく 間違いを取り消すための新しい変更差分を追加する 動きをします。チーム開発において、過去の整合性を壊さずに安全にミスを修正するための方法です。

まとめ

今回紹介した基本的な操作（Clone, Commit, Push, Fetch, Branch, Merge, Stash, Discard, Revert）をマスターすれば、日々の開発業務の大部分はGitHub Desktopだけで十分に完結させることが可能です。
UIの優れた視覚的フィードバックは、ソースコードの差分管理を圧倒的に楽にしてくれます。操作に慣れると感動を覚えることでしょう。

しかし、今回見てきたように、ボタン一つで実行される操作の裏側では、複雑なGitコマンドがいくつも組み合わさって動いています。
ツールが勝手にやってくれることに甘えすぎると、予期せぬコンフリクトやデータの消失に直面した際、何が起きたのか判断できず、解決に多大な時間を費やすことになります。

当たり前に使っているツールを単なる 便利なボタンの集まり として ブラックボックス化させないこと。 これが、いざという時に自分やチームのコードを守るための、エンジニアとしての確かな地力に繋がると考えています。

まずは

このボタン（UI）を押したら、裏ではどんな命令（API/コマンド）が動いているんだろう？

と、頭の中で一度イメージする習慣を付けてみてください。その 裏側への想像力 こそが、GitHub Desktop に限らず、開発ツールというエンジニアの強力な武器を真に使いこなすための第一歩となるはずです。

お知らせ

技術ブログを週1〜2本更新中、ソーイをフォローして最新記事をチェック！
https://qiita.com/organizations/sewii