Git CUIチートシート｜基本操作・ブランチ運用・マージ手順まで体系整理

CUI操作に慣れたつもりでも、いざという場面で「あれ、何のコマンドだっけ？」と手が止まることがある。テンプレート100本以上を作り込む中で、ChatGPTにgit操作の一部を任せた際、「merge」と「rebase」の出力が毎回変わることに気づいた。その揺らぎを検証する過程で、やはり人の側も“構造的な理解”を持っておく必要があると痛感した。

この記事は、そうした経験を踏まえ、「Git CUIの基本操作から応用までを、実務で使える構造で整理」することを目的に書きました。手元の自分用の備忘録としても、コマンドの意味を再確認したいときのリファレンスとしても、役立つ一枚になるはずです。

>>Amazonのお得な最新のタイムセール情報はここ

サーバー管理者歴17年の筆者が選んだレンタルサーバーはここ

ドコモ home 5G「キャッシュバック15,000円」を進呈中！

Git CUIの意義と使いどころ

GUIツールに慣れていても、CUI操作が必要になる場面は確実に存在します。
筆者自身も普段はForkを使っているものの、CIトラブル調査やSSH先での作業時には「結局CUIが一番確実だった」と再認識することが多々あります。

CUI操作が重要な理由

• どんな環境でも通用する
  → GUIが使えないサーバーでも、CUIなら確実にGit操作が可能。
• CI/CDの自動処理のトラブル調査に必須
  → 実行ログや履歴の追跡では、git log や diff を手で打って確認するしかない場面がある。
• スクリプトによる一括処理が可能
  → 複数リポジトリを対象とした一括更新やバックアップなど、CUIなら自動化が容易。

GUIでは見えにくい「Gitの動作原理」が分かる

CUIで操作することで、Gitの仕組みそのものがよく見えるようになります。
たとえば rebase や reset のような履歴操作は、GUIの抽象化では把握しにくく、コマンド実行を通じて初めて「何がどう動いているか」が実感できるようになります。

Git基本操作ガイド【初学者向け】

Gitをこれから使い始める人や、実務で「基本だけ押さえておきたい」人に向けた操作ガイドです。
このセクションでは、初期設定〜コミット〜履歴確認といった、一連の流れをシンプルに紹介します。

リポジトリ初期化とユーザー設定

• リポジトリの作成（初期化）
  git init で .git フォルダが作成され、ローカルリポジトリが開始されます。
• ユーザー名とメールの設定（初回のみ）
  git config --global user.name "Your Name"
git config --global user.email "you@example.com"
• ※ –global (グローバル設定)すれば全リポジトリ共通。個別に設定することも可能です。
• ※ リポジトリごとに別のユーザー情報を設定の場合は、--globalを外してリポジトリ内で実行します。

ステージングとコミットの基本

• 変更状況の確認 → git status
  追跡対象か、ステージ済みか、未コミットかが一覧で分かります。
• 変更の追加
  – ファイル単体：git add ファイル名
  – 一括追加：git add .
• コミットの作成
  git commit -m "変更内容の説明"
  ローカルリポジトリに履歴が記録されます。

状態確認と履歴調査の基本

• 履歴一覧の確認
  git log で全履歴、git log --oneline で簡易表示が可能。
• 差分の確認
  – 作業中の差分：git diff
  – 1つ前との比較：git diff HEAD~1
• 特定ファイルだけの履歴を追う
  git log ファイル名 で、ファイル単位の変更履歴を確認できます。

このセクションで登場した基本コマンド一覧

ブランチの作成・切り替え・管理

Gitのブランチは、「作業の分岐点」を柔軟に作れる強力な機能です。
機能ごとの開発、バグ修正の切り分け、他の作業への影響を防ぐために活用されます。

ここでは、ブランチの作成・切り替え・確認・削除といった基本操作に加え、git switch の登場による操作の変化も整理します。

ブランチの作成と切り替え

• ブランチを作るだけ：git branch feature/login
  → ブランチは作成されるが、まだ切り替わっていない状態。
• 作成と同時に切り替える：git checkout -b feature/login
  → こちらのほうが一般的。1コマンドで切り替えまで完了。
• 既存ブランチに移動：git checkout main または git switch main
  → Git 2.23以降は switch が推奨。
• 新しいブランチへ切り替えつつ作成：git switch -c feature/signup
  → -c は --create の略。安全かつ直感的なコマンド。

ブランチ一覧・削除・リモート操作

• ローカルのブランチ一覧：git branch
  → 現在のブランチには * マークが付く。
• リモートブランチも含めて表示：git branch -a
  → remotes/origin/ブランチ名 のように表示される。
• ローカルブランチを削除：git branch -d feature/login
  → -D で未マージでも強制削除可能。
• リモートブランチを削除：git push origin --delete feature/login

checkout / switch / restore の使い分けチャート

Git 2.23以降では、機能を明確に分けた新コマンドが登場しました。

• ブランチの切り替え専用 → git switch
• ファイルの復元専用 → git restore
• 従来の統合型コマンド → git checkout

用途がはっきり分かれてきたため、初心者にも安心して使える構造に進化しています。

ブランチ操作コマンド チートシート

git switch の使い方をケーススタディで理解する

Git 2.23以降で登場した git switch は、ブランチの切り替え専用コマンドです。
従来の git checkout と比べて操作が明確に分離され、より直感的に扱えるようになりました。

ここでは具体的な操作シーンをもとに、git switch の活用パターンを整理します。

ケース1：既存の main ブランチに移動したい

状況：
作業ブランチにいたが、元の main ブランチに戻りたい。

対応コマンド：
git switch main

結果：
作業ブランチから main に切り替わる。
ステージされていない変更があるとエラーや警告が出ることがあるため、事前に git status の確認が安心。

ケース2：新しい作業用ブランチを作って切り替えたい

状況：
main ブランチから feature/login というブランチを新規作成し、そこへすぐ移動したい。

対応コマンド：
git switch -c feature/login

結果：
feature/login という新しいブランチが作成され、そのまま移動する。
-c は --create の省略形で、新規ブランチ作成を意味する。

ケース3：誤って checkout を使いそうになる

状況：
従来の経験で git checkout を打ちかけたが、switch の方が安全だと気づいた。

対応判断：

• git checkout は切り替えとファイル復元を兼ねるため、誤操作のリスクがある
• git switch は「ブランチ専用」なので、操作ミスを防ぎやすい

推奨アクション： 今後は switch と restore を使い分ける習慣にすることで、安全性が向上する。

ケース4：作業内容が未保存で切り替えができないとき

状況：
変更中のファイルがある状態でブランチを切り替えようとしたらエラーが出た。

対応手順：

• git status で状態を確認
• git stash で変更を一時退避
• git switch 目的のブランチ名 で切り替え

ポイント： switch は未コミットの変更があると切り替えを拒否する仕様。
切り替え前に stash しておくのが安全策。

git switch コマンド チートシート

git switch の基本操作を目的別に一覧で整理しました。旧来の checkout との違いも併せて確認できます。

git restore の使い方をケーススタディで理解する

Git 2.23以降で登場した git restore は、ファイルの変更取り消しに特化した直感的なコマンドです。ここでは実際の操作シーンを想定しながら、具体的な使い方と注意点を整理します。

ケース1：作業中のファイル変更を取り消したい（未ステージ）

状況：
index.html を変更して保存したが、「やっぱりこの変更は不要だった」と気づいた。

対応コマンド：
git restore index.html

結果：
作業ディレクトリの index.html が最後のコミット状態に戻る。ステージされていない変更だけが対象。

注意： 一度実行すると、変更内容は元に戻せない（undoできない）ため、本当に不要かを事前に確認しておくのが安心。

ケース2：git add してしまったけど、やっぱりステージを取り消したい

状況：
main.css を git add したが、まだコミットしたくない。

対応コマンド：
git restore --staged main.css

結果：
ステージ領域から main.css が外れ、再び「変更済み・未ステージ」の状態に戻る。作業内容はそのまま保持される。

補足： 同じことは git reset HEAD main.css でも可能。ただし restore のほうが目的別に整理されていてわかりやすい。

ケース3：両方の取り消し（ステージと作業内容の両方）

状況：
app.js に変更を加え、git add もしてしまったが、すべてなかったことにしたい。

対応コマンド：
git restore --source=HEAD --staged --worktree app.js

結果：
コミット時点までファイルが完全に戻る。作業ツリーとステージ両方を巻き戻す操作。

注意： 明示的で安全な巻き戻しだが、強力なため慎重に扱う。

ケース4：GUIと併用していたが、差異が出て混乱したとき

状況：
SourceTreeやForkなどのGUIツールで変更が混在し、どのファイルを戻すか迷ってしまった。

対応方法：

• git status で状態確認
• 戻したいファイルに対して git restore ファイル名

ポイント： git restore はファイル単位で部分的に巻き戻しできるので、GUIで追えない細かい操作に向いている。

git restore コマンド チートシート

Git 2.23以降で導入された git restore の使い分けを一覧表にまとめました。状況に応じて安全に操作できるよう、目的別に整理しています。

リモート操作と同期の基本

Gitのローカル操作に慣れてきたら、いよいよ「リモートとの連携」が必要になります。
GitHubやGitLabなどの共有リポジトリを使うことで、チーム開発やバックアップ、自動デプロイが可能になります。

このセクションでは、リモートリポジトリの接続・取得・同期の基本操作を整理します。

リモートリポジトリの操作

• クローン（初回取得）
  git clone https://github.com/user/repo.git
  → 指定URLのリモートリポジトリを丸ごと複製します。
• 登録済みリモート一覧を見る
  git remote -v
  → origin などの名前付きURLを確認できます。
• 新しくリモートを登録
  git remote add origin URL
  → origin という別名でリモートを登録。
• 不要なリモート設定を削除
  git remote remove origin
  → リモートURLが間違っていたときなどに使います。

リモートとの同期：push / pull / fetch の違い

• push（ローカルの変更を送信）
  git push origin main
  → 自分の変更をリモートの main ブランチへ反映。
• pull（リモートの変更を取得＆統合）
  git pull origin main
  → 最新の変更を取り込み、自動的にマージも行われます。
• fetch（取得だけして差分確認）
  git fetch origin
  → ローカルの履歴には反映せず、差分を確認したいときに便利。

リモート操作コマンド チートシート

マージ vs リベース【実務視点】

複数ブランチでの作業を統合する際、Gitでは主に2つの手段があります：マージ（merge）とリベース（rebase）。
どちらも目的は「変更の統合」ですが、履歴の扱いや使うタイミングに大きな違いがあります。

このセクションでは、それぞれの特徴・利点・注意点を、実務に沿って解説します。

merge：分岐と統合の履歴を明示したいときに使う

• 基本コマンド：
  git merge ブランチ名
• 特徴：
  – マージコミットが履歴に残る（分岐と統合の形が明確に可視化）
  – チームでの作業やコードレビューで履歴が追いやすい
  – コンフリクト発生時は手動で解決し、add → commit が必要
• 向いている場面：
  – 複数人での開発
  – レビューや監査などで「誰がどの変更を統合したか」を履歴で残したい場合

rebase：履歴をシンプルに整理したいときに使う

• 基本コマンド：
  git rebase ブランチ名
• 特徴：
  – 履歴が1本に繋がる（分岐が見えなくなる）
  – コミットが再作成されるため、共有リポジトリに対して使うと危険
  – -i オプションでコミットの並べ替えや結合も可能（インタラクティブリベース）
• 向いている場面：
  – ソロ開発やPull Request前の履歴整理
  – 他人と共有していない、自分のローカルブランチ

どちらを使う？ 判断基準まとめ

merge / rebase コマンド チートシート

履歴整理・復元・巻き戻し

作業中の変更を一時退避したいとき、誤ってコミットした内容を取り消したいとき、過去の状態に戻したいとき。Gitはこれらの状況にも柔軟に対応できる仕組みを持っています。ここでは、履歴操作や一時退避を行う際に使う主要コマンドと、注意点をまとめます。

stash での一時退避

作業中の変更を一時的に避けておきたい場合に活用できるのが git stash です。

• 変更中の作業を保存し、作業ツリーをクリーンに戻す
• あとで再適用（stash pop / apply）することが可能
• 複数のstashを一覧で確認（stash list）、個別に参照（stash show）・削除（stash drop）できる

利用シーン例：
緊急のバグ修正対応などで、現在の作業を一時中断したいとき
変更をコミットする前に、別ブランチで試したいとき

revert, reset の違いと使い分け

履歴の巻き戻しには大きく2つの方法があります。それぞれの特徴と用途を理解しておくことが重要です。

git revert の特徴：
指定したコミットの変更を“打ち消す”新しいコミットを作成する。履歴を保ちつつ、論理的に取り消したいときに有効。チーム作業時に安全。

git reset の特徴：
HEADやブランチのポインタを指定したコミットに戻す。戻し方には –soft / –mixed / –hard の3種類がある。

• --soft：コミットだけ戻す（ステージング内容は残る）
• --mixed：ステージングも解除（作業ディレクトリは維持）
• --hard：作業内容ごと完全に巻き戻す（注意！）

使い分けの指針：
公開リポジトリやチーム作業中は revert を推奨。ローカルで自分の作業を整理したい場合は reset を活用。

reflog 活用法

Gitには表向きの履歴とは別に、「過去のHEADの移動履歴」を記録する git reflog という仕組みがあります。

• 削除したブランチや失ったコミットの“入口”を見つけられる
• git reset と組み合わせて、過去の状態に戻すことが可能

具体例：
誤って git reset --hard してしまったが、戻したい
git checkout で古い状態を探したい

注意：reflogはローカル限定。一定期間が過ぎると消えるため、早めの復元が肝心です。

タグ管理の基礎

Gitにおける「タグ（tag）」は、特定のコミットに名前を付けて記録する機能です。リリースの節目や重要な変更点に対して、わかりやすい目印を付けることで、履歴を参照しやすくなります。

タグの作成・削除・表示（tag, show, push, –tags）

• タグの作成
  git tag v1.0.0
  現在のコミットに v1.0.0 という軽量タグを付ける
• 注釈付きタグ
  git tag -a v1.0.0 -m "Initial release"
  コメント情報付きの正式なタグ
• タグ一覧を確認
  git tag
• タグの詳細を表示
  git show v1.0.0
• タグの削除
  git tag -d v1.0.0
• リモートにタグをプッシュ
  git push origin v1.0.0
• ローカルの全タグを一括プッシュ
  git push origin --tags

特定のコミットとタグを紐付ける方法

タグは任意のコミットに付けることもできます。
git tag v1.0.0 <コミットID> のように、履歴の中の任意のコミットに対して設定できます。

使いどころ例：
・安定版リリースの区切り
・ホットフィックスの直前後を明示
・検証用スナップショットの保存

タグは変更履歴の「固定点」として、後から見返す際の大きな助けになります。CI/CDパイプラインでは、タグをトリガーとして自動デプロイを実行する構成も一般的です。

操作フローの具体例（main→作業ブランチ→マージ）

仮想ケース：あなたはWebサービスのフロントエンド開発を担当中。本番ブランチ（main）から「ログインフォームのデザイン修正」を行い、作業完了後にmainへ統合したいとします。

このような場面で、Gitを使ってブランチを切り、作業を進め、最終的にmainへマージするまでの基本フローをSTEP形式で整理しました。初学者にも理解しやすい構成となっています。

実務で役立つGit応用テクニック集

Gitの基本操作に慣れてきたら、もう一歩踏み込んだ“実務的なコマンド”を覚えておくと、いざというときに役立ちます。このセクションでは、チーム開発やバグ調査、作業効率化の観点から、使用頻度の高い応用コマンドをチートシート形式で紹介します。

特定コミットだけ取り込む：git cherry-pick

別ブランチの特定コミット1件だけを取り込みたいときに使います。バグ修正やホットフィックス対応時によく登場します。

git cherry-pick <コミットID>
指定コミットの内容が現在のブランチに適用されます。

バグ原因を絞り込む：git bisect

「どのコミットでバグが入ったか」を二分探索で探せるコマンド。長期間の履歴の中から原因を効率的に特定できます。

git bisect start
git bisect bad
git bisect good <古い正常なコミット>

未追跡ファイルを一掃：git clean

コンパイル生成物やテスト用ファイルなど、Git未追跡の不要ファイルを削除したいときに便利です。

git clean -fd
-f（強制）と -d（ディレクトリ含む）に注意。

複数ブランチを並行作業：git worktree

1つのリポジトリから別ディレクトリにブランチを展開して作業できる機能。mainとfeatureブランチを同時に扱いたい場面で重宝します。

git worktree add ../dir-name ブランチ名

ショートカット化：alias 設定

Gitコマンドに短縮名を付けて素早く操作可能にします。例：git st で status を呼び出せるように。

git config --global alias.st status
git config --global alias.co checkout

知っておきたい便利オプション集

• git diff --cached：ステージとの差分確認
• git log --graph --oneline：履歴の構造を視覚化
• git fetch --prune：削除されたリモートブランチを整理

応用コマンド チートシート

よくあるトラブルと解決Q&A

Gitを使っていて、戸惑いやすい場面、間違えやすい操作に関する質問と回答をまとめました。初心者から中級者まで「一度は出くわす」トラブルを中心に構成しています。

あわせて読みたい

Git GUIツール「Fork」入門｜初心者にやさしい高機能Gitクライアント はじめてGitを触ったとき、うっかりgit reset –hardを実行してしまい、コミット履歴ごと吹き飛ばしたことがあります。 手元の変更がすべて消えたあの瞬間、どこをどう…