gitコマンド チートシート

リポジトリのセットアップ ✨

新しいGitリポジトリを作成したり、既存のリポジトリを取得したりします。

新しいリポジトリの作成 (`git init`)

カレントディレクトリをGitリポジトリとして初期化します。.git ディレクトリが作成されます。

# カレントディレクトリに .git ディレクトリを作成
git init

# 指定したディレクトリにリポジトリを作成
git init <ディレクトリ名>

# ベアリポジトリとして初期化 (作業ディレクトリなし、共有用)
git init --bare

# ベアリポジトリを特定のディレクトリに作成
git init --bare <ディレクトリ名>.git

# 初期ブランチ名を指定して初期化 (例: main)
git init -b main
git init --initial-branch=main

--bare オプションで作成されたリポジトリは、主にサーバー上で中央リポジトリとして使用され、直接ファイルを編集することはありません。

既存リポジトリのクローン (`git clone`)

リモートにある既存のGitリポジトリをローカル環境に複製します。

# リモートリポジトリをクローン (HTTPS経由)
git clone https://github.com/user/repo.git

# リモートリポジトリをクローン (SSH経由)
git clone git@github.com:user/repo.git

# 特定のディレクトリ名を指定してクローン
git clone <リポジトリURL> <ディレクトリ名>

# 特定のブランチを指定してクローン
git clone -b <ブランチ名> <リポジトリURL>
git clone --branch <ブランチ名> <リポジトリURL>

# 履歴を浅くしてクローン (最新のNコミットのみ)
git clone --depth <N> <リポジトリURL>

# シングルブランチのみクローン (指定ブランチのみ)
git clone --single-branch <リポジトリURL>

# サブモジュールも含めてクローン
git clone --recursive <リポジトリURL>
git clone --recurse-submodules <リポジトリURL>

基本的な操作 ⚙️

日々の開発で最もよく使う、変更の記録や状態確認に関するコマンドです。

変更をステージングする (`git add`)

作業ディレクトリの変更を、次のコミットに含めるためにステージングエリア（インデックス）に追加します。

# 特定のファイルを追加
git add <ファイル名>

# 複数のファイルを指定して追加
git add <ファイル1> <ファイル2>

# 特定のディレクトリ以下の変更を全て追加
git add <ディレクトリ名>/

# カレントディレクトリ以下の全ての変更（新規ファイル、変更されたファイル）を追加
git add .

# 変更があった全てのファイル（追跡中のファイルのみ、新規ファイルは含まない）を追加
git add -u
git add --update

# 削除されたファイルも含め、ワーキングツリーの全ての変更を追加 (Git 2.x 以降推奨)
git add -A
git add --all

# 対話的に追加するファイルや変更箇所を選択する (パッチモード)
git add -p
git add --patch

# ドライラン: 実際にaddせず、何がaddされるか確認
git add -n
git add --dry-run

git add . はカレントディレクトリ以下の変更、git add -u は追跡中のファイルの変更、git add -A はワーキングツリー全体の変更をステージングします。意図しないファイルを追加しないよう、範囲を意識して使い分けることが重要です。

変更をコミットする (`git commit`)

ステージングエリアに追加された変更を、ローカルリポジトリの履歴に記録します。

# エディタを開いてコミットメッセージを入力
git commit

# コミットメッセージを直接指定 (-m オプション)
git commit -m "コミットメッセージ"

# 複数行のコミットメッセージを指定
git commit -m "タイトル" -m "詳細な説明..."

# ステージングとコミットを同時に行う (追跡中のファイルの変更のみ)
git commit -a -m "コミットメッセージ"
# git commit -a は git add -u && git commit とほぼ同等

# 直前のコミットを修正する (--amend オプション)
# ステージングエリアの内容で上書きし、コミットメッセージもエディタで変更可能
git commit --amend

# メッセージはそのままで、ステージングエリアの内容だけ追加して修正
git commit --amend --no-edit

# 特定のファイルのみを対象にコミット (ステージングされていない変更は含まれない)
# (通常は git add してから git commit するのが一般的)
# git commit <ファイル1> <ファイル2> -m "メッセージ" # 非推奨に近い

# 空のコミットを作成（マージコミットの起点、CI/CDトリガーなどに使用）
git commit --allow-empty -m "空のコミット"

# コミット日時を指定する
git commit --date="YYYY-MM-DD HH:MM:SS" -m "過去の日時でコミット"

# GPG署名付きでコミット
git commit -S -m "署名付きコミット"

--amend は直前のコミットを書き換える操作です。既にリモートリポジトリにプッシュしたコミットを --amend して再度プッシュする場合、git push --force または git push --force-with-lease が必要になり、他の開発者の履歴とコンフリクトを引き起こす可能性があります。共有ブランチでの安易な --amend は避けましょう。

状態を確認する (`git status`)

作業ディレクトリとステージングエリアの状態を表示します。どのファイルが変更されたか、ステージングされているかなどを確認できます。

# 現在の状態を表示 (標準形式)
git status

# 短縮形式で表示 (-s または --short)
git status -s
# 例:
# M  README.md  (M = Modified, ステージング済み)
#  M Makefile   ( M = Modified, 未ステージング)
# ?? new_file.txt (?? = Untracked)
# A  added_file.js (A = Added, ステージング済み)
# AM modified_and_staged.py (AM = Added then Modified)

# ブランチ情報も表示 (-b または --branch)
git status -b
# 例: ## main...origin/main [ahead 1]

# 無視されているファイルも表示 (--ignored)
git status --ignored

# 詳細な情報を表示 (-v または --verbose)
# ステージングされていない変更内容の差分も表示
git status -v

コミット履歴を表示する (`git log`)

リポジトリのコミット履歴を表示します。

# 全てのコミット履歴を表示
git log

# コミット履歴を一行で表示
git log --oneline

# コミット履歴をグラフ形式で表示 (ブランチのマージ状況が分かりやすい)
git log --graph --oneline --decorate --all

# 特定のファイルの変更履歴を表示
git log <ファイル名>

# 特定のディレクトリの変更履歴を表示
git log <ディレクトリ名>/

# 指定した数のコミット履歴のみ表示
git log -n <数>
git log -5 # 最新5件

# 特定の期間のコミットを表示
git log --since="YYYY-MM-DD"
git log --until="YYYY-MM-DD"
git log --since="2 weeks ago"

# 特定のコミットメッセージを含むコミットを検索
git log --grep="キーワード"

# 特定のコミット者によるコミットを表示
git log --author="名前またはメールアドレス"

# 変更内容の差分 (パッチ) も表示
git log -p
git log --patch

# 各コミットで変更されたファイルのリストを表示
git log --stat

# カスタムフォーマットで表示
git log --pretty=format:"%h %ad | %s%d [%an]" --date=short --graph

変更差分を表示する (`git diff`)

コミット間、ブランチ間、作業ディレクトリとステージングエリア間などの差分を表示します。

# 作業ディレクトリ vs ステージングエリアの差分
git diff

# ステージングエリア vs 最新コミット (HEAD) の差分
git diff --staged
git diff --cached

# 作業ディレクトリ vs 最新コミット (HEAD) の差分
git diff HEAD

# 特定のファイルについての作業ディレクトリ vs ステージングエリアの差分
git diff <ファイル名>

# 特定のファイルについてのステージングエリア vs 最新コミットの差分
git diff --staged <ファイル名>

# 2つのコミット間の差分
git diff <コミットID1> <コミットID2>

# 特定のコミットとその親コミットとの差分
git diff <コミットID>^ <コミットID>
git diff <コミットID>~1 <コミットID> # 上と同じ

# 2つのブランチ間の差分
git diff <ブランチ名1> <ブランチ名2>
# 例: main ブランチに対する develop ブランチの変更点
git diff main...develop # main と develop の共通祖先から develop までの変更

# 差分を色付きで表示 (通常デフォルトで有効)
git diff --color

# 空白文字の変更を無視
git diff -w
git diff --ignore-all-space

# 差分サマリー (変更ファイル一覧と変更の種類) を表示
git diff --stat

# ファイル名のみ表示
git diff --name-only

# 変更されたファイル名とその状態 (A:追加, M:修正, D:削除など) を表示
git diff --name-status

ブランチ操作 🌿

Gitの強力な機能であるブランチを作成、切り替え、統合するためのコマンドです。

ブランチの一覧・作成・削除 (`git branch`)

# ローカルブランチの一覧表示
git branch

# リモート追跡ブランチも含めて一覧表示
git branch -a
git branch --all

# リモート追跡ブランチのみ一覧表示
git branch -r
git branch --remotes

# 現在のブランチ名のみ表示
git branch --show-current

# 新しいブランチを作成 (現在のコミットから分岐)
git branch <新しいブランチ名>

# 特定のコミットやブランチから新しいブランチを作成
git branch <新しいブランチ名> <起点となるコミット/ブランチ名>

# ブランチ名を変更 (現在のブランチ)
git branch -m <新しいブランチ名>

# 特定のブランチ名を変更
git branch -m <古いブランチ名> <新しいブランチ名>

# マージ済みのブランチを削除 (-d: --delete)
# 安全な削除。マージされていない変更があると削除できない。
git branch -d <ブランチ名>

# マージされていないブランチを強制的に削除 (-D: --delete --force)
git branch -D <ブランチ名>

# リモート追跡ブランチの情報を更新 (削除されたリモートブランチ情報をローカルに反映)
git remote prune origin
git fetch --prune # fetch と同時に prune する

# リモートブランチを削除 (実際にはリモートに削除コマンドを push する)
git push origin --delete <リモートブランチ名>
git push origin :<リモートブランチ名> # 古い構文

-D オプションによる強制削除は、そのブランチの変更が不要であることが確実な場合にのみ使用してください。失われたコミットは復元が困難な場合があります。

ブランチの切り替え (`git checkout`, `git switch`)

作業するブランチを切り替えます。Git 2.23 からは、より安全で目的に特化した `git switch` が推奨されます。

# 既存のブランチに切り替え (git checkout)
git checkout <ブランチ名>

# 既存のブランチに切り替え (git switch - 推奨)
git switch <ブランチ名>

# 新しいブランチを作成して、すぐにそのブランチに切り替え (git checkout)
git checkout -b <新しいブランチ名>

# 新しいブランチを作成して、すぐにそのブランチに切り替え (git switch - 推奨)
git switch -c <新しいブランチ名>
git switch --create <新しいブランチ名>

# 特定のコミットやタグの状態に切り替え (detached HEAD 状態になる)
git checkout <コミットID/タグ名>

# リモート追跡ブランチを元に、ローカルブランチを作成して切り替え
git checkout -b <ローカルブランチ名> origin/<リモートブランチ名>
# 対応するローカルブランチがない場合、自動で作成・追跡設定して切り替え (推奨)
git switch <リモートブランチ名と同じ名前> # 例: `git switch feature/new-func` (origin/feature/new-func が存在する場合)
git checkout --track origin/<リモートブランチ名> # 古い方法

# 直前のブランチに切り替え
git checkout -
git switch -

# 作業ディレクトリの変更を破棄して、HEADの状態に戻す (特定のファイル)
git checkout -- <ファイル名>
# 注意: この変更は元に戻せません！

# 作業ディレクトリの変更を破棄して、HEADの状態に戻す (全てのファイル)
git checkout .
# 注意: この変更は元に戻せません！

# 特定のコミットからファイルを取得して作業ディレクトリに復元
git checkout <コミットID> -- <ファイル名>

`git switch` はブランチ切り替え専用、`git restore` はファイルの状態復元専用コマンドとして導入されました。従来の `git checkout` は多機能すぎたため、これらの新しいコマンドを使うことで意図しない操作を防ぎやすくなります。

ファイルの復元 (`git restore`)

Git 2.23 から導入された、作業ディレクトリやステージングエリアの変更を取り消すためのコマンドです。

# 作業ディレクトリの変更を取り消し、HEADの状態に戻す (特定のファイル)
git restore <ファイル名>

# 作業ディレクトリの変更を取り消し、HEADの状態に戻す (カレントディレクトリ以下全て)
git restore .

# ステージングエリアから変更を取り除く (unstage)
git restore --staged <ファイル名>

# ステージングエリアから全ての変更を取り除く
git restore --staged .

# 作業ディレクトリとステージングエリアの両方の変更を、特定のコミットの状態に戻す
git restore --source=<コミットID> --staged --worktree <ファイル名>

# 作業ディレクトリの変更を、特定のコミットの状態に戻す
git restore --source=<コミットID> <ファイル名>

`git restore` による作業ディレクトリの変更取り消しは、元に戻すことができません。実行前に `git status` や `git diff` で状態をよく確認してください。

ブランチの統合 (`git merge`)

指定したブランチの変更履歴を、現在のブランチに取り込みます。

# 現在チェックアウトしているブランチに、指定したブランチをマージする
git merge <マージするブランチ名>

# マージコミットを必ず作成する (Fast-forward マージを抑制)
git merge --no-ff <マージするブランチ名>

# マージを実行せず、マージコミットのメッセージのみ編集する
git merge --edit <マージするブランチ名>

# マージを実行せず、コミットもしない (コンフリクト解決後に手動でコミット)
git merge --no-commit <マージするブランチ名>

# マージを中断する (コンフリクト発生時など)
git merge --abort

# Squash マージ: 統合するブランチのコミットを一つにまとめてからマージする
# マージ先の履歴はシンプルになるが、元のブランチのコミット履歴は失われる
git merge --squash <マージするブランチ名>
# --squash の後、手動で git commit する必要がある

マージ時にコンフリクトが発生した場合、Gitはファイル内にコンフリクト箇所をマーカー（<<<<<<<, =======, >>>>>>>）で示します。ファイルを編集してコンフリクトを解決し、git add でステージングしてから git commit を実行（または git merge --continue）してマージを完了させます。解決できない場合は git merge --abort でマージ開始前の状態に戻せます。

コミット履歴の付け替え (`git rebase`)

現在のブランチの基点（分岐元）を、指定したブランチの最新コミットに変更し、その上に現在のブランチのコミットを一つずつ適用し直します。履歴を直線的に整理できます。

# 現在のブランチのコミットを、指定したブランチの先端に移動する
# 例: feature ブランチを main ブランチの最新に追従させる
# (feature ブランチをチェックアウトした状態で実行)
git rebase main

# 対話的リベース (Interactive Rebase): コミットの編集、並べ替え、統合、削除などを行う
git rebase -i <起点となるコミットIDの親>
git rebase -i HEAD~<N> # 直近 N 個のコミットを対象にする
git rebase -i --root # ルートコミットまで遡る

# リベースを中断する (コンフリクト発生時など)
git rebase --abort

# コンフリクト解決後、リベースを続行する
git add <解決したファイル>
git rebase --continue

# 特定のコミットをスキップしてリベースを続行する
git rebase --skip

# マージコミットを保持しながらリベースする (-p, --preserve-merges は非推奨)
# 代わりに --rebase-merges を使う (より複雑な履歴に対応)
git rebase --rebase-merges <新しい基点>

git rebase はコミット履歴を書き換える操作です。git merge と異なり、元のコミットは破棄され新しいコミットIDが生成されます。既にリモートリポジトリにプッシュしたブランチに対してリベースを行うと、他の開発者の履歴と不整合が生じるため、原則として共有ブランチでのリベースは避けるべきです。もし実行した場合は git push --force または git push --force-with-lease が必要になります。

対話的リベース (git rebase -i) は非常に強力なツールで、コミット履歴を綺麗に整えるのに役立ちます。主なコマンドには pick (そのまま使用), reword (コミットメッセージ編集), edit (コミット内容修正), squash (前のコミットと統合、メッセージは結合), fixup (前のコミットと統合、メッセージは破棄), drop (コミット削除) などがあります。

特定のコミットを取り込む (`git cherry-pick`)

他のブランチにある特定のコミットを、現在のブランチにコピーして適用します。

# 指定したコミットを現在のブランチに適用
git cherry-pick <コミットID>

# 複数のコミットを順番に適用
git cherry-pick <コミットID1> <コミットID2>

# コミット範囲を指定して適用 (コミットID1 の次から コミットID2 まで)
git cherry-pick <コミットID1>..<コミットID2> # ID1 は含まない
git cherry-pick ^<コミットID1> <コミットID2>   # ID1 を含む場合

# コミットせずに、変更内容をワーキングツリーとインデックスに適用
git cherry-pick -n <コミットID>
git cherry-pick --no-commit <コミットID>

# コンフリクト発生時に中断する
git cherry-pick --abort

# コンフリクト解決後、チェリーピックを続行する
git add <解決したファイル>
git cherry-pick --continue

# チェリーピックを中止して次のコミットへスキップする（複数指定時）
git cherry-pick --skip

# マージコミットをチェリーピックする場合 (親番号を指定)
# 通常はマージコミット自体ではなく、変更内容を含む個別のコミットをピックする方が良い
git cherry-pick -m <親番号(通常1か2)> <マージコミットID>

Cherry-pick は、特定の修正や機能を別のブランチに素早く取り込みたい場合に便利ですが、乱用すると履歴が複雑になる可能性があります。可能な限り、ブランチのマージやリベースで対応できないか検討しましょう。

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

ローカルリポジトリとリモートリポジトリ間でデータをやり取りするためのコマンドです。

リモートリポジトリの管理 (`git remote`)

接続しているリモートリポジトリの情報を管理します。

# 登録されているリモートリポジトリの一覧表示
git remote

# リモートリポジトリ名とそのURLを表示
git remote -v

# 新しいリモートリポジトリを登録
git remote add <リモート名> <リポジトリURL>
# 例: git remote add origin git@github.com:user/repo.git

# リモートリポジトリのURLを変更
git remote set-url <リモート名> <新しいURL>

# リモートリポジトリの登録を解除
git remote remove <リモート名>
git remote rm <リモート名>

# リモートリポジトリの名前を変更
git remote rename <古いリモート名> <新しいリモート名>

# 特定のリモートリポジトリの詳細情報を表示 (URL、追跡ブランチなど)
git remote show <リモート名>
# 例: git remote show origin

# リモートで削除されたブランチ情報をローカルの追跡ブランチから削除
git remote prune <リモート名>
# 例: git remote prune origin

通常、git clone でリポジトリを取得すると、origin という名前でクローン元のリポジトリが自動的にリモートとして登録されます。

リモートの変更を取得 (`git fetch`)

リモートリポジトリから最新の情報を取得しますが、ローカルの作業ブランチにはマージしません。リモート追跡ブランチ（例: origin/main）が更新されます。

# デフォルトのリモート (origin) から全てのブランチの情報を取得
git fetch

# 特定のリモートリポジトリから取得
git fetch <リモート名>
# 例: git fetch upstream

# 特定のリモートの特定のブランチのみ取得
git fetch <リモート名> <ブランチ名>
# 例: git fetch origin main

# リモートで削除されたブランチ情報をローカルに反映 (--prune)
git fetch --prune
git fetch -p

# 全てのリモートリポジトリから取得
git fetch --all

# タグ情報も取得
git fetch --tags

# シャロークローンで取得した履歴を深くする
git fetch --depth=<新しい深さ>
git fetch --unshallow # 全履歴を取得

git fetch はローカルの作業内容に影響を与えずにリモートの状態を確認・取得できるため、git pull を行う前に実行して差分を確認する（例: git log HEAD..origin/main）といった使い方が安全です。

リモートの変更を取得してマージ (`git pull`)

リモートリポジトリから最新の情報を取得し、現在のローカルブランチに自動的にマージします。内部的には git fetch と git merge (または git rebase) を連続して実行するショートカットです。

# 現在のブランチが追跡しているリモートブランチから取得してマージ
git pull

# 特定のリモートリポジトリの特定のブランチを取得して、現在のブランチにマージ
git pull <リモート名> <リモートブランチ名>
# 例: git pull origin main

# マージの代わりにリベースを行う (--rebase)
# ローカルのコミットをリモートの最新コミットの上に付け替える
git pull --rebase
# git config --global pull.rebase true でデフォルトに設定可能

# Fast-forward マージのみ許可 (--ff-only)
# 履歴が分岐している場合はエラーとなり、マージコミットが作られない
git pull --ff-only

# 自動マージをせず、フェッチのみ行う (git fetch と同じ)
# git pull --no-commit # これはマージ後のコミットをしないオプション

# サブモジュールも更新
git pull --recurse-submodules

git pull はローカルの変更とリモートの変更を自動でマージするため、予期せぬコンフリクトが発生することがあります。特に複数人で共同作業している場合、まず git fetch でリモートの変更を確認し、必要に応じてローカルの変更をコミットまたはスタッシュしてから git merge origin/<ブランチ名> や git rebase origin/<ブランチ名> を手動で行う方が安全な場合があります。git pull --rebase は履歴をきれいに保てますが、マージコミットが失われる点に注意が必要です。

ローカルの変更をリモートに送信 (`git push`)

ローカルリポジトリのコミットをリモートリポジトリにアップロードします。

# 現在のブランチのコミットを、対応するリモートブランチ (upstream) にプッシュ
git push

# 特定のリモートリポジトリの特定のブランチにプッシュ
git push <リモート名> <ローカルブランチ名>:<リモートブランチ名>
# 例: git push origin main:main

# ローカルブランチ名とリモートブランチ名が同じ場合は省略可能
git push <リモート名> <ブランチ名>
# 例: git push origin feature/new

# 現在のブランチを、同じ名前のリモートブランチにプッシュし、追跡関係 (upstream) を設定 (-u)
git push -u <リモート名> <ブランチ名>
# 例: git push -u origin feature/add-login
# 一度 -u を付けて push すれば、次回からは git push だけでOK

# 全てのローカルブランチを対応するリモートブランチにプッシュ
git push --all <リモート名>

# タグ情報をプッシュ
git push --tags <リモート名>
git push <リモート名> <タグ名> # 特定のタグをプッシュ

# リモートブランチを削除
git push <リモート名> --delete <リモートブランチ名>
git push <リモート名> :<リモートブランチ名> # 古い構文

# リモートの履歴を強制的に上書き (-f, --force)
# 注意: 他の人の変更を消す可能性があり非常に危険！
git push -f <リモート名> <ブランチ名>
git push --force <リモート名> <ブランチ名>

# より安全な強制プッシュ (--force-with-lease)
# リモートブランチがローカルの知る状態から更新されていない場合のみ強制プッシュを許可
git push --force-with-lease <リモート名> <ブランチ名>

git push --force はリモートリポジトリの履歴を強制的に書き換えます。もし他の誰かがあなたが知らない変更をリモートにプッシュしていた場合、その変更は失われます。共同開発中の共有ブランチに対して --force を使うのは原則として避けるべきです。履歴の書き換えが必要な場合は、必ず事前にチームメンバーと調整し、--force-with-lease の使用を検討してください。--force-with-lease は、ローカルのリモート追跡ブランチがリモートリポジトリの実際の状態と同じであることを確認してからプッシュするため、意図しない上書きのリスクを低減できます。

変更の取り消し・修正 ↩️

コミットや作業ディレクトリの変更を取り消したり、修正したりするためのコマンドです。

コミットの取り消し (`git reset`)

HEADやブランチの位置、ステージングエリア、作業ディレクトリの状態を指定したコミットの状態に戻します。モードによって影響範囲が異なります。

# 直前のコミットを取り消し、変更をステージングエリアに残す (soft)
git reset --soft HEAD~1

# 直前のコミットを取り消し、変更を作業ディレクトリに残す (mixed, デフォルト)
git reset HEAD~1
git reset --mixed HEAD~1

# 直前のコミットを取り消し、変更も全て破棄する (hard) - 注意！
git reset --hard HEAD~1

# 特定のコミットまで履歴を戻す (例: 3つ前のコミット)
git reset HEAD~3 # --mixed モード
git reset --soft HEAD~3
git reset --hard HEAD~3 # 注意！

# 特定のコミットIDの状態に戻る
git reset <コミットID>
git reset --hard <コミットID> # 注意！

# ステージングエリアの特定のファイルを取り消す (git restore --staged と同等)
git reset HEAD <ファイル名>
git reset <ファイル名> # 上と同じ

# ステージングエリアの全てのファイルを取り消す
git reset HEAD .
git reset .

git reset --hard は作業ディレクトリの内容も書き換えるため、コミットしていない変更が失われます。元に戻すのは困難なため、使用前に必ず状態を確認してください。リモートにプッシュ済みのコミットを reset した場合、履歴の整合性を取るために git push --force または --force-with-lease が必要になります。

コミットを打ち消す新しいコミットを作成 (`git revert`)

指定したコミットが行った変更を打ち消すための新しいコミットを作成します。既存の履歴は変更せずに、特定の変更の影響を安全に取り除くことができます。

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

# コミットメッセージを編集せずに revert コミットを作成
git revert --no-edit <打ち消したいコミットID>

# 自動でコミットせず、変更内容をステージングエリアに適用
git revert -n <打ち消したいコミットID>
git revert --no-commit <打ち消したいコミットID>

# マージコミットを revert する場合 (親番号を指定)
# マージによって取り込まれた変更全体を打ち消す
git revert -m <親番号(通常1)> <マージコミットID>

git revert は既存のコミット履歴を書き換えないため、リモートリポジトリにプッシュ済みのコミットの変更を取り消したい場合に安全な方法です。git reset と異なり、過去の「間違い」が履歴に残り、それを「修正」したという事実も記録されます。

追跡されていないファイルの削除 (`git clean`)

作業ディレクトリにある、Gitで追跡されていないファイル（Untracked files）を削除します。ビルド生成物などを一括で削除するのに便利です。

# 削除されるファイルを表示する (ドライラン)
git clean -n

# 追跡されていないファイルを削除
# (-f または --force が必須。意図しない削除を防ぐため)
git clean -f

# 追跡されていないディレクトリも削除 (-d)
git clean -fd

# .gitignore で無視されているファイルも削除 (-x)
git clean -fx
git clean -fdx # ディレクトリも含む

# 対話的に削除するファイルを選択 (-i)
git clean -i

git clean は削除したファイルを元に戻すことができません。特に -x オプションは .gitignore ファイルで意図的に無視しているファイルまで削除するため、実行前に必ず git clean -n で削除対象を確認してください。

直前のコミットの修正 (`git commit –amend`)

直前のコミットを修正します。ステージングエリアの内容を追加したり、コミットメッセージを修正したりできます。（基本的な操作の `git commit` セクションも参照）

# ファイルを追加し忘れた場合
git add <追加し忘れたファイル>
git commit --amend --no-edit # メッセージは変えずにコミット

# コミットメッセージだけ修正したい場合
git commit --amend
# (ステージングエリアに変更がなければ、メッセージ編集のみ行われる)

# 変更を追加し、メッセージも修正する場合
git add <修正ファイル>
git commit --amend

--amend はコミット履歴を書き換えます。プッシュ済みのコミットを修正した場合は、git push --force または --force-with-lease が必要になります。

タグ操作 🏷️

特定のコミットに対して、バージョン名などの分かりやすい名前（タグ）を付けるためのコマンドです。

タグの一覧・作成・削除 (`git tag`)

# タグの一覧表示
git tag

# 特定のパターンに一致するタグを表示 (ワイルドカード使用可)
git tag -l "v1.*"

# 軽量タグ (Lightweight Tag) を作成 (特定のコミットを指すだけ)
# 現在のHEADに対して作成
git tag <タグ名>
# 特定のコミットに対して作成
git tag <タグ名> <コミットID>

# 注釈付きタグ (Annotated Tag) を作成 (タグ付け者、日付、メッセージを含むオブジェクト)
# エディタでメッセージを入力
git tag -a <タグ名>
# メッセージを直接指定
git tag -a <タグ名> -m "タグのメッセージ"
# 特定のコミットに対して作成
git tag -a <タグ名> <コミットID> -m "メッセージ"

# GPG署名付きタグを作成 (-s)
git tag -s <タグ名> -m "署名付きタグ"

# 特定のタグの詳細情報を表示
git show <タグ名>

# ローカルのタグを削除
git tag -d <タグ名>

# リモートリポジトリに全てのタグをプッシュ
git push --tags <リモート名>
git push origin --tags

# 特定のタグをリモートリポジトリにプッシュ
git push <リモート名> <タグ名>
git push origin v1.0.0

# リモートリポジトリのタグを削除
git push <リモート名> --delete <タグ名>
git push origin --delete v1.0.0
git push <リモート名> :refs/tags/<タグ名> # 古い構文

一般的に、リリースポイントなど重要なコミットには、作成者や日付、メッセージ情報を含む「注釈付きタグ」を使用することが推奨されます。軽量タグは一時的な目印などに使われます。

履歴の調査・分析 🔍

特定の変更がいつ、誰によって行われたかなどを調査するためのコマンドです。

コミット履歴の高度な表示 (`git log`)

基本的な `git log` に加えて、より詳細な情報や特定の条件での検索が可能です。（基本的な操作の `git log` セクションも参照）

# 特定の文字列が追加または削除されたコミットを検索 (-S オプション: Pickaxe)
git log -S"特定のコードや文字列"

# 正規表現でコミットメッセージを検索 (--grep と --perl-regexp など)
git log --grep="^feat:" --perl-regexp

# 指定した範囲のコミットを表示 (コミットAの次からコミットBまで)
git log <コミットA>..<コミットB>

# 2つのブランチ間で、片方にのみ存在するコミットを表示
# 例: main にはなくて develop にのみ存在するコミット
git log main..develop

# 変更された行数だけでなく、実際の変更内容 (diff) を表示
git log -p <ファイル名>

# マージコミットのみ表示
git log --merges

# マージコミットを除外して表示
git log --no-merges

# コミットの親子関係を表示
git log --parents

ファイルの各行の最終変更者を表示 (`git blame`)

指定したファイルの各行が、どのコミットで、誰によって最後に変更されたかを表示します。

# ファイルの各行の最終変更情報を表示
git blame <ファイル名>

# 特定の行範囲を指定して表示 (-L オプション)
git blame -L <開始行>,<終了行> <ファイル名>
git blame -L 10,20 main.js

# 空白文字の変更を無視 (-w)
git blame -w <ファイル名>

# メールアドレスを表示 (-e)
git blame -e <ファイル名>

# コミットIDを短縮形で表示 (-c, または設定による)
# git blame -c <ファイル名> # Gitバージョンによる挙動変化あり

# 特定のコミット時点での blame 情報を表示
git blame <コミットID> -- <ファイル名>

git blame はバグの原因となった変更箇所や、特定のコードに関する質問相手を見つけるのに役立ちます。「blame（非難する）」という名前ですが、犯人探しではなく、変更の経緯を理解するために使いましょう。

特定のオブジェクトの詳細表示 (`git show`)

コミット、タグ、ツリー、ブロブ（ファイル内容）など、Gitオブジェクトの詳細情報を表示します。

# 最新のコミット (HEAD) の詳細情報を表示 (ログ + 差分)
git show

# 特定のコミットの詳細情報を表示
git show <コミットID>

# 特定のタグの詳細情報を表示 (注釈付きタグの場合はタグ情報も)
git show <タグ名>

# 特定のコミットにおけるファイルのツリーオブジェクトを表示
git show <コミットID>:<ディレクトリパス>
# 例: git show HEAD:src/

# 特定のコミットにおけるファイルの内容 (ブロブオブジェクト) を表示
git show <コミットID>:<ファイルパス>
# 例: git show v1.0:README.md

設定の管理 (`git config`) 🔧

Gitの動作をカスタマイズするための設定を行います。設定はシステム全体、ユーザーごと、リポジトリごとに適用できます。

設定の表示・変更

# 全ての設定を表示 (ローカル、グローバル、システムの設定を統合)
git config --list

# 設定の適用元ファイルも表示
git config --list --show-origin

# ローカルリポジトリ (.git/config) の設定を表示
git config --local --list

# ユーザー全体 (~/.gitconfig) の設定を表示
git config --global --list

# システム全体 (/etc/gitconfig) の設定を表示
git config --system --list

# 特定の設定値を取得
git config <設定キー>
# 例: git config user.name

# ローカルリポジトリに設定を追加・変更
git config --local <設定キー> <値>
# 例: git config --local user.email "repo-specific@example.com"

# ユーザー全体に設定を追加・変更 (--global)
git config --global <設定キー> <値>
# 例: git config --global user.name "Your Name"
# 例: git config --global core.editor "vim"
# 例: git config --global alias.st status # エイリアス設定

# 設定を削除
git config --unset <設定キー>
# 例: git config --global --unset alias.st

# 設定ファイルを直接編集 (デフォルトエディタで開く)
git config --edit # ローカル設定 (--local)
git config --global --edit # グローバル設定
git config --system --edit # システム設定

設定の優先順位は、ローカル > グローバル > システム です。同じキーが設定されている場合、より限定的な範囲（ローカル）の設定が優先されます。最初に user.name と user.email をグローバル設定で登録しておくことが重要です。

一時的な変更の退避 (`git stash`) 📦

まだコミットしたくない作業中の変更を一時的に退避させるためのコマンドです。ブランチを切り替える前などに便利です。

変更の退避・適用・削除

# 作業ディレクトリとステージングエリアの変更を退避
git stash
git stash save "任意のメッセージ" # メッセージ付きで退避

# 退避時に追跡されていないファイル (Untracked files) も含める (-u)
git stash -u
git stash --include-untracked

# 退避時に無視されているファイル (Ignored files) も含める (-a)
# (-u も自動的に含まれる)
git stash -a
git stash --all

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

# 最新の退避した変更を適用し、スタッシュリストから削除 (pop)
git stash pop
# 特定のスタッシュを適用して削除 (例: stash@{1})
git stash pop stash@{1}

# 最新の退避した変更を適用するが、スタッシュリストには残す (apply)
git stash apply
# 特定のスタッシュを適用して残す
git stash apply stash@{1}

# 退避した変更内容の差分を表示
git stash show # 最新のスタッシュの差分サマリー
git stash show stash@{1} # 特定のスタッシュの差分サマリー
git stash show -p # 最新のスタッシュの差分詳細 (パッチ形式)
git stash show -p stash@{1} # 特定のスタッシュの差分詳細

# 最新の退避した変更を削除
git stash drop
# 特定の退避した変更を削除
git stash drop stash@{1}

# 全ての退避した変更を削除
git stash clear

# 退避した変更から新しいブランチを作成して適用
git stash branch <新しいブランチ名> stash@{<スタッシュ番号>}
# 例: git stash branch feature/from-stash stash@{0}

git stash pop や git stash apply 時にコンフリクトが発生することがあります。その場合はコンフリクトを解決し、手動で git add してから、必要に応じてコミットします。pop の場合、コンフリクトが解決されるまでスタッシュはリストから削除されません。