git 実践コマンド集 2026年版【よく使うシーン別まとめ】

2026年2月28日

---

git を使って毎日コードを書いているのに「このコマンド、どう書くんだっけ？」と手が止まることはないだろうか。git log のオプションを毎回調べ直す、rebase と merge をどっちにすべか迷う、stash からどう戻すか忘れる——そういった「知ってるようで都度調べる」状態から抜け出すための記事がこれだ。

チームで Git を使う場面を想定し、ブランチ作成からマージ・コンフリクト解消・履歴整理・リモート操作まで、シーン別に実際のコマンドと出力例をセットでまとめた。コピペして使えるレベルで書いている。

筆者自身がプロダクション環境で日常的に使っているコマンド群を元に、2026年時点での標準的な使い方にアップデートして掲載している。

---

前提条件

このガイドは以下の環境を前提としている。

• 環境: Linux / macOS / Windows（WSL2 推奨）
• 必要なツール: Git 2.40 以上
• 前提知識: コマンドライン基本操作、Git の基本概念（リポジトリ・コミット・ブランチ）

# バージョン確認
git --version
# 期待する出力例: git version 2.47.2

注意: Git 2.28 以降で init.defaultBranch 設定が追加されている。古いバージョンだとデフォルトブランチ名が master になる場合がある。

---

全体の流れ

このガイドは以下のシーンに対応した構成になっている。

1. 初期設定・リポジトリ操作 — リポジトリを使い始める
2. ブランチ・コミット操作 — 日々の開発サイクル
3. マージ・リベース・コンフリクト解消 — 統合作業
4. リモート操作・プッシュ・プル — チーム連携
5. stash・一時退避と復元 — 作業の中断と再開
6. 履歴確認・git log 活用 — コードの追跡
7. revert・reset・修正系コマンド — ミスのリカバリ
8. タグ・バージョン管理 — リリース管理
9. 応用・エイリアス・設定最適化

---

シーン1: 初期設定・リポジトリ操作

グローバル設定（最初にやること）

新しい開発環境に入ったら最初にやる設定。コミットに名前とメールが記録されるため、チームの規約に合わせて設定する。

git config --global user.name "Yamada Taro"
git config --global user.email "yamada@example.com"

# エディタを設定（vim / nano / vscode 等）
git config --global core.editor "vim"

# デフォルトブランチ名を main に設定（Git 2.28+）
git config --global init.defaultBranch main

# 設定内容を確認
git config --list

リポジトリの初期化とクローン

# 新規リポジトリを作成
git init my-project
cd my-project

# 既存のリモートリポジトリをクローン
git clone https://github.com/user/repo.git

# クローン先ディレクトリ名を指定する場合
git clone https://github.com/user/repo.git custom-dir

# 特定のブランチのみクローン（サイズが大きいリポジトリに有効）
git clone --single-branch --branch develop https://github.com/user/repo.git

# 浅いクローン（最新のコミットだけ取得。CIで高速化したいとき）
git clone --depth 1 https://github.com/user/repo.git

よくあるミス: --depth 1 でクローンした場合、git log で過去の履歴が見えない。CI用途には有効だが、開発目的では避けたほうがよい。

✅ シーン1完了の確認: git log が動く、git remote -v でリモートURLが表示される。

---

シーン2: ブランチ・コミット操作

日常の開発サイクルで最も頻繁に使うコマンド群。

ブランチ操作

# ブランチ一覧を確認（ローカル）
git branch

# ブランチ一覧を確認（リモート含む）
git branch -a

# 新しいブランチを作成して切り替え
git switch -c feature/add-login

# 既存のブランチに切り替え
git switch main

# 旧来の checkout を使う場合
git checkout -b feature/add-login
git checkout main

# ブランチを削除（マージ済みのもの）
git branch -d feature/old-feature

# ブランチを強制削除（未マージでも）
git branch -D feature/abandoned

補足: Git 2.23 以降では git switch と git restore が導入された。checkout は多機能すぎて混乱しやすいため、現在は switch / restore の使用が推奨されている。

ステージング・コミット

# 変更ファイルの状態を確認
git status

# 変更内容の差分を確認（ステージ前）
git diff

# ステージ済みとの差分を確認
git diff --staged

# 特定のファイルをステージ
git add src/login.js

# 全変更をステージ
git add .

# 対話的にハンクを選択してステージ（部分コミットに便利）
git add -p

# コミット
git commit -m "feat: ログイン機能を追加"

# ステージとコミットを一気に行う（新規ファイルは対象外）
git commit -am "fix: バリデーションエラーを修正"

# コミットメッセージを修正（最新コミットのみ、プッシュ前）
git commit --amend -m "feat: ログイン・ログアウト機能を追加"

.gitignore の設定

# .gitignore に追加するパターン例
echo "node_modules/" >> .gitignore
echo ".env" >> .gitignore
echo "*.log" >> .gitignore

# 既にトラッキングされているファイルをgitignore対象にする
git rm --cached .env

✅ シーン2完了の確認: git log --oneline でコミット履歴が表示される。

---

シーン3: マージ・リベース・コンフリクト解消

チーム開発での統合作業。merge と rebase の使い分けがポイントになる。

merge

# main ブランチに feature ブランチをマージ
git switch main
git merge feature/add-login

# マージコミットを作らない fast-forward マージ
git merge --ff-only feature/hotfix

# 必ずマージコミットを作る（履歴を明確にしたいとき）
git merge --no-ff feature/add-login -m "Merge: ログイン機能を統合"

# マージをキャンセル（コンフリクト対応中に中止したいとき）
git merge --abort

rebase

# feature ブランチを main の先頭に付け替える
git switch feature/add-login
git rebase main

# 対話的 rebase（コミットの整理・squash・順序変更）
git rebase -i HEAD~3

# rebase をキャンセル
git rebase --abort

# コンフリクト解消後に rebase を続行
git rebase --continue

merge vs rebase の選び方:

状況	推奨
チームの共有ブランチ（main / develop）への統合	merge --no-ff
フィーチャーブランチを最新の main に同期	rebase
PRを出す前にコミットを整理したい	rebase -i
共有済みブランチ（他メンバーも使っている）	rebase は避ける

コンフリクトの解消手順

# マージ中にコンフリクトが発生した場合
git status
# both modified: src/config.js のように表示される

# コンフリクトマーカーを含むファイルを確認
cat src/config.js
# <<<<<<< HEAD
# const API_URL = "https://api.example.com";
# =======
# const API_URL = "https://api.staging.example.com";
# >>>>>>> feature/add-login

# エディタでコンフリクトを解消後、ステージ
git add src/config.js

# マージを完了
git commit

コンフリクト解消ツール: git mergetool でビジュアルなマージツール（vimdiff / VS Code等）を起動できる。git config --global merge.tool vimdiff で設定可能。

✅ シーン3完了の確認: git log --graph --oneline でブランチが統合されていることを確認。

---

シーン4: リモート操作・プッシュ・プル

リモート管理

# リモートの一覧を確認
git remote -v

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

# リモートURLを変更（HTTPS → SSH等）
git remote set-url origin git@github.com:user/repo.git

# リモートを削除
git remote remove upstream

fetch / pull / push

# リモートの変更を取得（ローカルには反映しない）
git fetch origin

# リモートの変更をフェッチしてマージ
git pull origin main

# rebase して pull（マージコミットを作らない）
git pull --rebase origin main

# プッシュ（ブランチを指定）
git push origin feature/add-login

# ブランチを初めてプッシュして上流追跡を設定
git push -u origin feature/add-login

# 上流設定済みなら省略可
git push

# タグもプッシュ
git push origin --tags

# リモートのブランチを削除
git push origin --delete feature/old-feature

# 強制プッシュ（--force-with-lease が安全）
git push --force-with-lease origin feature/add-login

--force vs --force-with-lease: --force はリモートの状態を確認せず上書きするため危険。--force-with-lease はリモートブランチが自分の最後のフェッチ以降に変わっていた場合はプッシュを拒否する。rebase 後のプッシュには常に --force-with-lease を使うべきだ。

✅ シーン4完了の確認: git log origin/main でリモートの最新コミットが確認できる。

---

シーン5: stash・一時退避と復元

作業中断が必要な場面で stash は必須の道具になる。

# 作業を一時退避
git stash

# メッセージ付きで退避（後で探しやすい）
git stash push -m "WIP: ログインフォームのスタイル調整中"

# 新規ファイル（untracked）も一緒に退避
git stash -u

# stash 一覧を確認
git stash list
# 出力例:
# stash@{0}: WIP on feature/add-login: abc1234 feat: フォームを追加
# stash@{1}: On feature/add-login: WIP: ログインフォームのスタイル調整中

# 最新の stash を取り出して適用（stashから削除）
git stash pop

# 特定の stash を適用（削除はしない）
git stash apply stash@{1}

# stash の変更内容を確認
git stash show -p stash@{0}

# 特定の stash を削除
git stash drop stash@{1}

# 全 stash を削除
git stash clear

よくある落とし穴: git stash pop でコンフリクトが発生した場合、stash は自動的に削除されない。git stash list で確認し、解消後に git stash drop する必要がある。

✅ シーン5完了の確認: git stash list が空、または意図したとおりに stash が残っている。

---

シーン6: 履歴確認・git log 活用

git log は奥が深い。デフォルトの出力では情報が多すぎるので、用途に合わせたオプションを覚えると作業効率が大きく変わる。

# 基本のログ
git log

# 1行表示（概要確認に便利）
git log --oneline

# ブランチの分岐・マージをグラフで表示
git log --oneline --graph --all

# 直近5件だけ表示
git log -5

# 特定ファイルの変更履歴
git log --follow src/login.js

# 変更差分も一緒に表示
git log -p src/login.js

# 特定のキーワードを含むコミットを検索
git log --grep="ログイン"

# 特定の文字列が追加・削除されたコミットを検索（pickaxe）
git log -S "const API_URL"

# 特定の日時範囲
git log --after="2026-01-01" --before="2026-02-01"

# 特定の作者のコミット
git log --author="Yamada"

# 書式をカスタマイズ
git log --pretty=format:"%h %ad %s [%an]" --date=short

blame・変更箇所の特定

# 各行が最後にどのコミットで変更されたかを確認
git blame src/login.js

# 特定の行範囲だけ表示（例: 10〜20行目）
git blame -L 10,20 src/login.js

# 特定のコミット時点での blame
git blame abc1234 -- src/login.js

✅ シーン6完了の確認: ブランチのマージ履歴がグラフで確認できる。

---

シーン7: revert・reset・修正系コマンド

ミスをしたときのリカバリ手順。操作によっては履歴が書き換わるため、プッシュ済みかどうかで使うべきコマンドが変わる。

revert（安全・公開済みコミットに）

# 特定のコミットを打ち消す新しいコミットを作成
git revert abc1234

# 複数コミットをまとめて revert
git revert HEAD~3..HEAD

# コミットを作成せず変更だけ適用（後で手動コミット）
git revert -n abc1234

reset（ローカルのみ。プッシュ前に使う）

# ステージを取り消す（ファイル変更は保持）
git reset HEAD src/login.js

# 直前のコミットを取り消す（変更はワーキングツリーに残る）
git reset --soft HEAD~1

# 直前のコミットとステージを取り消す（変更はワーキングツリーに残る）
git reset --mixed HEAD~1

# 直前のコミットを完全に取り消す（変更も消える・危険）
git reset --hard HEAD~1

# リモートの状態に強制的に合わせる（ローカルの変更が全て消える）
git reset --hard origin/main

reset の比較:

オプション	コミット	ステージ	ワーキングツリー
--soft	取り消す	保持	保持
--mixed	取り消す	取り消す	保持
--hard	取り消す	取り消す	取り消す

restore（ファイル単位の操作）

# ワーキングツリーの変更を元に戻す（git checkout -- と同じ）
git restore src/login.js

# ステージを取り消す
git restore --staged src/login.js

# 特定のコミット時点のファイル内容に戻す
git restore --source=abc1234 src/login.js

cherry-pick（特定コミットだけを取り込む）

# 別のブランチの特定コミットだけを現在のブランチに適用
git cherry-pick abc1234

# 複数コミットを適用
git cherry-pick abc1234 def5678

# コミットを作成せず変更だけ適用
git cherry-pick -n abc1234

✅ シーン7完了の確認: git log --oneline で意図した状態になっていることを確認。

---

シーン8: タグ・バージョン管理

リリース時のバージョン管理にはタグを使う。

# タグ一覧を確認
git tag

# 軽量タグを作成
git tag v1.0.0

# 注釈付きタグを作成（リリースノートに使う）
git tag -a v1.0.0 -m "Release v1.0.0: ログイン機能追加"

# 特定のコミットにタグを付ける
git tag -a v0.9.0 abc1234 -m "Release v0.9.0"

# タグの詳細を確認
git show v1.0.0

# タグをリモートにプッシュ
git push origin v1.0.0

# 全タグをプッシュ
git push origin --tags

# タグを削除（ローカル）
git tag -d v0.9.0

# タグを削除（リモート）
git push origin --delete v0.9.0

# タグからブランチを作成（バージョンのバグ修正用）
git switch -c hotfix/v1.0.1 v1.0.0

✅ シーン8完了の確認: git tag -l "v*" でバージョンタグが一覧表示される。

---

応用編: エイリアスと設定最適化

繰り返し使うコマンドはエイリアスに登録すると作業効率が上がる。

よく使うエイリアス設定

# ~/.gitconfig に追加、または git config --global で設定
git config --global alias.st "status"
git config --global alias.co "switch"
git config --global alias.br "branch"
git config --global alias.lg "log --oneline --graph --all"
git config --global alias.last "log -1 HEAD --stat"
git config --global alias.unstage "restore --staged"

グローバル .gitignore

# OS・エディタ固有のファイルをグローバルに除外
git config --global core.excludesfile ~/.gitignore_global

# ~/.gitignore_global の内容例
cat ~/.gitignore_global
# .DS_Store
# Thumbs.db
# .idea/
# .vscode/
# *.swp

rebase を pull のデフォルトにする

# pull 時に常に rebase を使う（マージコミットを作らない）
git config --global pull.rebase true

GitHub Actions への組み込み（CI での git 操作）

# .github/workflows/release.yml
name: Release
on:
  push:
    tags:
      - 'v*'
jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 全履歴が必要な場合（git log 等）
      - name: Get tag name
        run: echo "TAG=${GITHUB_REF#refs/tags/}" >> $GITHUB_ENV
      - name: Build and release
        run: |
          git log $(git describe --tags --abbrev=0 HEAD^)..HEAD --oneline

---

トラブルシュート

症状	原因	解決策
push を拒否される（non-fast-forward）	リモートに自分のローカルにないコミットがある	git pull --rebase 後に再度 push
コミットの名前・メールが間違っている	config が未設定	git commit --amend --reset-author
間違えてコミットした .env を消したい	.gitignore 設定前にコミットしてしまった	git rm --cached .env && git commit
rebase -i でエディタが開かない	core.editor が設定されていない	git config --global core.editor "vim"
detached HEAD 状態になった	タグやコミットハッシュを checkout した	git switch -c new-branch でブランチを作成するか git switch main で戻る
マージコミットが多く履歴が汚い	pull がデフォルトでマージしている	git config --global pull.rebase true を設定

---

まとめ

git のコマンドはシーンごとに使い分けが大切だ。

• ブランチ操作: git switch / git branch で日常の切り替えを効率化
• 統合作業: merge --no-ff と rebase を目的に応じて使い分ける
• リモート操作: --force-with-lease を使ってチームの変更を守る
• 履歴確認: git log --graph --oneline --all で全体像を把握
• ミスの修正: プッシュ前は reset、プッシュ後は revert が基本

git は「知っているコマンド数」より「適切なコマンドを適切な場面で使えるか」が重要だ。このリファレンスをブックマークして、迷ったときに参照してほしい。