Gitコマンド早見表｜現場でよく使うコマンドを用途別に整理

Gitは、ソースコードのバージョン管理に欠かせないツールです。しかし、コマンドの数が多く、必要なときに思い出せないことも少なくありません。この記事では、現場でよく使うGitコマンドを用途別に整理しました。ブックマークしておけば、困ったときにすぐ参照できる早見表として活用できます。Gitの基本概念を理解した上で読むと、より効果的です。

解説

Git コマンドチートシート とは

実務で使う頻度の高い Git コマンド (status / add / commit / push / pull / branch / merge / rebase など) を、目的別にまとめたリファレンスです。コピペで使える形にしてあります。

TL;DR 早わかりサマリー

• Git コマンドは「日常 8 割」「週次 1.5 割」「緊急 0.5 割」の 3 階層で頻度別に覚えると効率的
• 日常で使うのは add / commit / push / pull / status / log / diff / branch / checkout の 9 つ
• コンフリクト解消とリベース、強制 push の安全な使い方は中級者の壁
• .gitconfig + alias + GUI ツール (GitHub Desktop / GitKraken) との併用で生産性が一気に上がる

基本操作

Gitを使い始めるとき、最初に覚えるべきコマンド群です。

# リポジトリを新規作成する
git init

# 既存のリモートリポジトリをローカルに複製する
git clone https://github.com/user/repo.git

# 変更したファイルをステージングエリアに追加する
git add ファイル名

# すべての変更をステージングに追加する
git add .

# ステージングした変更をコミットする
git commit -m "コミットメッセージ"

# 現在の作業状態を確認する
git status

git status は最も頻繁に使うコマンドの一つです。今どのファイルが変更されているか、何がステージングされているかを把握するために、作業の節目ごとに実行する習慣をつけましょう。

ブランチ操作

ブランチは、メインのコードに影響を与えずに新機能の開発やバグ修正を進めるための仕組みです。

# ブランチの一覧を表示する
git branch

# 新しいブランチを作成する
git branch ブランチ名

# 指定したブランチに切り替える
git switch ブランチ名

# ブランチを作成して同時に切り替える
git switch -c ブランチ名

# 指定したブランチを現在のブランチに統合する
git merge ブランチ名

# 不要になったブランチを削除する
git branch -d ブランチ名

git switch は git checkout の後継として導入されたコマンドです。ブランチの切り替えには git switch を使うのが現在の推奨です。

リモート操作

チーム開発では、リモートリポジトリとの連携が不可欠です。GitHubの使い方入門と合わせて確認してください。

# リモートリポジトリの一覧を表示する
git remote -v

# リモートリポジトリを追加する
git remote add origin https://github.com/user/repo.git

# リモートの変更をローカルに取り込む（マージなし）
git fetch

# リモートの変更を取り込んでマージする
git pull origin main

# ローカルの変更をリモートに送信する
git push origin ブランチ名

# リモートブランチの一覧を表示する
git branch -r

git fetch と git pull の違いは重要です。fetch はリモートの情報を取得するだけで、ローカルのコードは変更しません。pull は fetch と merge を同時に実行します。チーム開発では、まず fetch で状況を確認してから merge するほうが安全です。

取り消し・修正

操作を間違えたときの対処法です。状況に応じて使い分けます。

# ステージングを取り消す（ファイルの変更は残る）
git restore --staged ファイル名

# ファイルの変更を元に戻す（未コミットの変更を破棄）
git restore ファイル名

# 直前のコミットメッセージを修正する
git commit --amend -m "修正後のメッセージ"

# 直前のコミットにファイルを追加する
git add 追加ファイル
git commit --amend --no-edit

# 指定したコミットまで戻す（変更はステージングに残る）
git reset --soft HEAD~1

# 指定したコミットまで戻す（変更は作業ディレクトリに残る）
git reset --mixed HEAD~1

# 指定したコミットの変更を打ち消す新しいコミットを作る
git revert コミットID

git reset と git revert は明確に異なります。reset はコミット履歴を書き換えるため、プッシュ済みのコミットには使うべきではありません。チームで共有しているブランチでは revert を使いましょう。

ログ・差分確認

コミット履歴や変更内容を確認するためのコマンドです。

# コミット履歴を表示する
git log

# コミット履歴を1行ずつ簡潔に表示する
git log --oneline

# ブランチの分岐をグラフで表示する
git log --oneline --graph

# 作業ディレクトリの変更差分を表示する
git diff

# ステージング済みの変更差分を表示する
git diff --staged

# 2つのブランチの差分を表示する
git diff main..feature

git log --oneline --graph は、ブランチの流れを視覚的に把握するのに便利です。複数人で開発しているときは特に重宝します。

スタッシュ

作業途中の変更を一時的に退避させる機能です。ブランチを切り替えたいが、今の変更はまだコミットしたくない、というときに使います。

# 作業中の変更を一時退避する
git stash

# メッセージ付きで退避する
git stash save "作業内容のメモ"

# 退避した変更の一覧を表示する
git stash list

# 最新の退避を復元する（退避リストから削除）
git stash pop

# 最新の退避を復元する（退避リストに残す）
git stash apply

# 退避した変更を削除する
git stash drop

stash pop は復元と同時に退避リストから削除します。復元後も退避を残しておきたい場合は stash apply を使いましょう。

困ったときの逆引き

よくある「こういうときどうする？」をまとめました。

間違えてコミットしてしまった

まだプッシュしていなければ git reset --soft HEAD~1 でコミットを取り消せます。変更内容はステージングに残るので、修正してから再度コミットできます。

コンフリクトが発生した

git status でコンフリクトが起きているファイルを確認し、エディタで <<<<<<< と >>>>>>> の間を手動で修正します。修正後、git add してから git commit で解決です。

間違ったブランチで作業してしまった

git stash で変更を退避し、正しいブランチに git switch で切り替えてから git stash pop で復元します。

プッシュ済みのコミットを取り消したい

git revert コミットID で、そのコミットの変更を打ち消す新しいコミットを作ります。履歴が残るため、チーム開発でも安全です。

特定のファイルだけ前のバージョンに戻したい

git restore --source=コミットID ファイル名 で、指定したコミット時点のファイル内容を復元できます。

Gitを実践で使いこなすために

Gitコマンドは、繰り返し使うことで自然と身につきます。この早見表を手元に置きつつ、実際のプロジェクトで試してみてください。特にブランチ操作とリモート操作は、チーム開発で毎日使う基本スキルです。

ゆめさくの「GitHub」コースでは、Gitの基本操作からプルリクエストを使ったチーム開発まで、実践的なワークフローを段階的に学べます。コマンドを覚えるだけでなく、現場で通用するGitの使い方を身につけたい方は、ぜひコースに取り組んでみてください。

日常コマンド早見表 (8 割の作業はこれだけ)

# ステータス確認
git status

# 変更を確認
git diff
git diff --staged

# 履歴確認
git log --oneline -10
git log --graph --oneline --all

# ステージング → コミット
git add .
git add -p  # インタラクティブにステージ
git commit -m "feat: ログイン機能を追加"

# プッシュ / プル
git push
git pull --rebase  # マージコミットを作らない

# ブランチ操作
git branch  # 一覧
git checkout -b feature/login  # 新規作成 + 切替
git switch main  # 切替 (新しい記法)
git branch -d feature/login  # 削除

# 取り消し
git restore <file>  # 変更を破棄
git restore --staged <file>  # ステージング解除
git reset --soft HEAD~1  # 直前のコミットを取り消し (変更は残す)

中級コマンド (週次で使う)

# リベース
git rebase main  # 自分のブランチを main の最新に追従
git rebase -i HEAD~3  # 直近 3 コミットを統合 / 編集

# スタッシュ (一時退避)
git stash
git stash pop

# タグ
git tag v1.0.0
git push origin v1.0.0

# リモート操作
git fetch origin
git remote -v
git remote add upstream <url>  # OSS フォーク時

# 部分チェックアウト
git checkout HEAD~3 -- path/to/file

緊急コマンド (事故対応)

# 過去のコミットに戻る (要注意)
git reset --hard HEAD~1

# 強制 push (チームに事前共有)
git push --force-with-lease

# 過去のコミットを取り消す (履歴は残す)
git revert <commit-hash>

# 削除したファイルを復元
git checkout <commit-hash> -- <file>

# reflog で「失った」コミットを救う
git reflog
git checkout HEAD@{2}

--force 系は要注意。--force-with-lease を使うと他人の変更を上書きしてしまうリスクを下げられます。詳しくは Git とは で概念から確認できます。

ハンズオン Step-by-Step

頻出 5 コマンドを 5 分で素振りします。新しいフォルダを 1 つ用意してそのまま手を動かしてください。

Step 1. 初期化と最初のコミット

リポジトリを初期化し、空コミットを 1 つ作って初期状態を整えます。

git init
git commit --allow-empty -m "init"

Step 2. ブランチを切って作業

main から feature/hello ブランチを作って切り替えます。

git checkout -b feature/hello

Step 3. ファイル変更 → add → commit

README を編集して 1 コミット作ります。

echo "hello" > README.md
git add README.md
git commit -m "add README"

Step 4. main に戻ってマージ

main に戻り、feature ブランチをマージします。

git checkout main
git merge feature/hello

Step 5. 履歴を 1 行で確認

git log --oneline --graph --all で、ブランチと合流が見やすく表示されます。

git log --oneline --graph --all

この 5 コマンドだけで個人開発の 9 割は回ります。慣れたら rebase と cherry-pick も覚えてみましょう。

関連リソース

• Git とは
• GitHub の使い方入門
• Webエンジニアロードマップ
• ポートフォリオの作り方
• Docker とは
• プログラミング学習のはじめ方コース

よくある質問

Q. Git の基本を体系的に学ぶには

A. Pro Git (公式無料書籍) + 自分のリポジトリで毎日使う、の 2 つが最も効率的。1-2 週間で日常コマンドは身につきます。詳しくは Git とは を参照してください。

Q. GUI ツールは使うべきですか

A. CLI で基本を覚えた後、GitHub Desktop / GitKraken / SourceTree などを併用するのがおすすめ。差分確認・コンフリクト解消は GUI の方が早いです。

Q. コンフリクトが怖いです

A. VS Code のマージエディタを使うと視覚的に解消できます。「Accept Current」「Accept Incoming」「Accept Both」を選ぶだけ。週 1 回コンフリクトを起こすつもりで慣れていくと早く上達します。

Q. リベースとマージ、どちらを使うべきですか

A. チームの方針に従うのが鉄則。一般的には feature ブランチ作業は rebase、main へのマージは merge commit で履歴を残す、のハイブリッドが多いです。

Q. 間違って push してしまったらどうしますか

A. git revert <commit> で「取り消しコミット」を作って push するのが最も安全。--force は他人と共有しているブランチでは絶対に NG です。

Q. Git と GitHub の違いは

A. Git = バージョン管理システム (ローカルで動く)、GitHub = Git ホスティングサービス (リモート連携 + Issue + PR + CI/CD)。両方をセットで使うのが標準です。詳しくは GitHub の使い方入門 を参照。

次に読むべきリソース

• 学習を始めたい方 — ポートフォリオ作成コース
• 深く理解したい方 — Git とは？
• 無料相談したい方 — ゆめさくエンジニア 無料相談

出典・参考リンク

本記事の主張・数値・仕様に関する根拠は、以下の一次情報・公式ドキュメントを参照しています。リンク先の更新により内容が変わる場合があるため、最新情報は各公式サイトで確認してください。

• Git 公式ドキュメント (Reference)
• Pro Git (日本語版)
• Git: git push リファレンス (--force-with-lease)
• GitHub Docs: About Git
• Git 公式ドキュメント
• GitHub Docs

この記事について

• 監修: 生田 陸人 (ゆめさくエンジニア エンジニア / 大手 IT 企業現役エンジニア)
• 公開: 2026-05-28
• 最終更新: 2026-05-28
• カテゴリ: 開発ツール
• 検証環境: Git 2.44 (macOS / Linux / Windows Git Bash)
• 編集ポリシー: 公式ドキュメント・公的統計を一次情報として優先し、社内エンジニアが実機検証した内容のみを掲載しています。修正提案や事実誤認の指摘は ゆめさく運営 までお寄せください。