Gitコマンド一覧｜よく使う基本コマンドの早見表と用途別の使い方・トラブル対処【Git 2.56対応】

Gitで日常的に打つコマンドは、初期設定・変更の記録・ブランチ・リモート連携・取り消しの5場面でほぼ尽きます。本記事は、よく使うコマンドとオプションを用途別の早見表にまとめ、続く章で使い方を実行例つきで解説します。後半には「git pull が止まった」「git push が拒否された」といったエラーメッセージから引く逆引き表も置きました。内容は2026年10月時点の最新版 Git 2.56.0 の公式ドキュメントで確認しました。出力例は Git 2.50.1（macOS 付属版）のもので、版や設定によって表示は変わります。

まとめ：よく使うGitコマンドは約20個、事故が起きやすいのは pull・push・reset

覚える順番は作業の流れどおりで構いません。

• 記録：git status で状態を見て、git add でステージし、git commit で確定する。
• ブランチ：作成と切り替えは git switch -c。Git 2.51.0 で git switch と git restore は「実験的」の表記が外れ、正式なコマンドになりました。
• リモート：取得は git fetch か git pull、送信は git push。
• 取り消し：手元の変更は git restore、push 済みのコミットは git revert。履歴を書き換える git reset は未 push のコミットだけに使う。

つまずきやすいのは3か所です。履歴が分岐していると git pull は統合せずに止まる。force push は --force-with-lease だけでは他人のコミットを消せてしまう。git reset --hard で消したコミットは git reflog から戻せる。この3つは後半の章で手順を示します。

Gitコマンド早見表（用途別・よく使うオプション付き）

使用頻度の高いコマンドを場面ごとに並べました。「よく使う形」は実際に打つことが多いオプションの組み合わせです。

表に無いコマンドやオプションは、手元のGitで引けます。git help -a がインストール済みの全コマンド、git <コマンド> -h がそのコマンドのオプション一覧（短い要約）、git help <コマンド> が完全なマニュアルを表示します。Web で読むなら公式の Git Reference（git-scm.com/docs）が最新版に追随しています。

初期設定とリポジトリ作成のコマンド（config・init・clone）

最初に一度だけ、コミットに記録される名前とメールアドレスを設定します。--global を付けるとそのユーザーの全リポジトリに効き、付けなければ今いるリポジトリだけに効きます。

git config --global user.name "Your Name"
git config --global user.email "[email protected]"

# 設定値と、その値を書いた設定ファイルを一覧表示する（Git 2.46以降）
git config list --show-origin

Git 2.46 で git config はサブコマンド形式（list・get・set）に移り、--list などの旧形式は非推奨になりました。旧形式もまだ動くため、2.46 より古い Git しか無い環境では git config --list --show-origin を使います。

新しく管理を始めるなら git init、既存のリモートを手元に複製するなら git clone です。

git init -b main
git clone https://github.com/user/repo.git

最初のブランチ名を -b（--initial-branch）や設定 init.defaultBranch で決められるようになったのは Git 2.28.0 からです。現行の Git 2.x は、何も設定しないと master で作ります。公式の BreakingChanges には、Git 3.0 で新規リポジトリの既定ブランチ名を main に変えると書かれていますが、3.0 のリリース日は「まだ決まっていない」とされています。GitHub などのリモートと名前をそろえるなら、git config --global init.defaultBranch main を一度実行しておくのが確実です。

手元のGitの版は git --version で確かめます。最新版との差やアップデート方法は「Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点」にまとめています。

変更を記録するコマンド（status・add・commit・diff・log）

Gitの記録は2段階です。git add で「次のコミットに入れる変更」をステージに載せ、git commit でまとめて確定します。作業中は git status をこまめに打ち、どの変更がステージ済みかを確かめます。

git status -s           # 1行表示。左の列＝ステージ済み、右の列＝未ステージ
git diff                # 未ステージの差分
git diff --staged       # ステージ済みの差分（コミットされる内容）
git commit -m "ログイン画面のバリデーションを追加"
git commit --amend      # 直前のコミットを作り直す（未 push に限る）

git add . と git add -A の違いは対象の範囲

Git 2.x では、どちらも削除を含む全種類の変更をステージします。違いは範囲です。git add . は「今いるディレクトリ以下」、git add -A は「リポジトリ全体」が対象になります。サブディレクトリ sub/ で git add . を実行しても、親ディレクトリの top.txt の削除は対象範囲の外なのでステージされません。

$ cd sub && git add . && git status -s
M  s.txt
 D ../top.txt      ← 右の列＝未ステージのまま

ステージする変更を選びたいときは git add -p が便利です。変更のかたまりごとに y／n で選べるので、無関係な修正を1つのコミットに混ぜずに済みます。

git log の見やすいオプション

履歴は git log --oneline --graph --all で、全ブランチの分岐と合流を1行ずつ表示できます。特定ファイルの履歴は git log -p -- <file>、文字列を追加・削除したコミットの検索は git log -S "関数名"、日付で絞るなら --since="2 weeks ago" を使います。グラフを画面で追いたい場合は、VS Code 拡張の「Git Graphの使い方」も参考になります。

ブランチ操作のコマンド（branch・switch・merge・rebase）

git branch              # ローカルのブランチ一覧（-a でリモート追跡ブランチも）
git switch -c feature/login   # 作成して切り替え
git switch main         # 既存ブランチへ切り替え
git switch -           # 直前のブランチへ戻る
git merge feature/login       # 今のブランチに統合
git branch -d feature/login   # 統合済みなら削除（未統合は -D で強制）

統合の方法は2つあります。git merge は通常、早送りできればブランチの先端だけを進め、履歴が分岐していればマージコミットを作ります。一方、git rebase は自分のコミットを相手ブランチの先端に付け替えて履歴を一直線にします。rebase はコミットのIDを作り直すので、他の人が取得済みのブランチには使わないでください。使い分けとコンフリクト時のやり直しは「git rebaseとは？使い方・mergeとの違い」で、細かいコミットを1つにまとめる手順は「git squashとは？」で解説しています。同じリポジトリで複数ブランチを同時に開きたいなら git worktree が使えます（「Git worktreeの使い方」）。

switch・restore と checkout の使い分け

git checkout は「ブランチの切り替え」と「ファイルの復元」の両方を担うため、git checkout main と git checkout -- main のように1語の違いで動作が変わります。この混乱を避けるため Git 2.23 で切り替え専用の git switch と復元専用の git restore が追加され、Git 2.51.0 のリリースノートで「もう実験的ではない」と宣言されました。

新しく覚えるなら switch と restore で十分で、廃止されていない git checkout は古い手順書で読めれば足ります。タグへの切り替えは git switch <タグ名> では失敗し、--detach が必要です。

リモート連携のコマンド（remote・fetch・pull・push）

git remote -v                 # 接続先の確認
git fetch --prune             # 取得のみ。リモートで消えたブランチの追跡も片付ける
git pull                      # fetch して今のブランチに統合
git push -u origin feature/login   # 初回 push。以降は git push だけで済む

git pull が止まるときの統合方式の設定（pull.rebase・pull.ff）

git pull の公式ドキュメントは、統合方式を4つ挙げ、早送り（fast-forward）だけを行う --ff-only を既定としています。手元とリモートの両方に新しいコミットがあって早送りできないと、設定が無い状態の git pull は統合せずに止まります。

$ git pull
hint: You have divergent branches and need to specify how to reconcile them.
hint:   git config pull.rebase false  # merge
hint:   git config pull.rebase true   # rebase
hint:   git config pull.ff only       # fast-forward only
fatal: Need to specify how to reconcile divergent branches.

チームの方針で1つ選んで設定します。自分のコミットをリモートの先に並べ直して履歴を一直線に保つなら git config --global pull.rebase true、早送りできる更新だけを自動で取り込むなら pull.ff only にして、止まったときに git rebase か git merge を手で打ちます。pull.rebase false は分岐するたびにマージコミットを作るため、main を頻繁に pull する運用では履歴が読みにくくなります。ブランチ運用やCIの組み立てまで含めて整えたい場合は、DevOps・CI/CD導入支援でもご相談を受けています。

force pushの保護：force-with-leaseとforce-if-includesの併用

rebase や --amend で手元の履歴を書き換えると、通常の git push は「non-fast-forward」で拒否されます。上書きが必要な場面でも --force は使わず、リモートが自分の知っている状態のときだけ上書きする --force-with-lease を使います。

ただし --force-with-lease の「知っている状態」はリモート追跡ブランチ（origin/main など）で判定されます。push の前に git fetch を実行していると（エディタの自動 fetch でも同じ）、他の人のコミットを取得しただけで統合していなくても上書きが通ってしまいます。別の人のコミットを fetch しただけで統合していない状態でも、引数なしの --force-with-lease は上書きを通し、そのコミットはリモートから消えます。次は Git 2.50.1 での出力例です。

# fetch 済み・未統合の他人のコミットがある状態
$ git push --force-with-lease --force-if-includes origin HEAD:main
 ! [rejected]        HEAD -> main (remote ref updated since checkout)

$ git push --force-with-lease origin HEAD:main
 + f8a3433...216474b HEAD -> main (forced update)   ← 他人のコミットが消えた

git push の公式ドキュメントによると、--force-if-includes はリモート追跡ブランチの先端が手元のブランチの reflog から到達できるか、つまり取り込み済みかを確かめてから上書きします。共有ブランチで force push をする可能性があるなら、git config --global push.useForceIfIncludes true を設定しておくと、--force-with-lease を付けたときに自動でこの確認が入ります。main や release など保護すべきブランチは、そもそもリモート側で force push を禁止しておくのが本筋です。

取り消し・やり直しのコマンド（restore・reset・revert・stash）

まず「その変更はもう push したか」で道具が分かれます。push 済みのコミットは、履歴を残したまま打ち消しコミットを作る git revert を使います。git reset は履歴そのものを書き換えるため、未 push のコミットに限ります。

「コミットメッセージを直したい」「入れ忘れたファイルを足したい」なら git commit --amend、「コミットをやめてステージの状態に戻したい」なら --soft が向いています。--hard は作業中の変更まで消すので、実行前に git status で未コミットの変更が無いことを確かめてください。マージの取り消し（git merge --abort・git revert -m 1）は「git mergeの取り消し｜abort・reset・revert -mの使い分け」で扱っています。

git stashの作業退避とpopで戻るステージの範囲

作業途中で別ブランチの修正に入るときは、変更を git stash で一時退避します。あとで見分けられるよう、メッセージを付ける push -m の形が便利です。

git stash push -m "ログイン画面 作業中"
git stash list          # stash@{0}: On main: ログイン画面 作業中
git stash pop           # 成功時に一覧から削除（apply は残す）。競合時は残る
# ステージ状態も復元する場合は、上のpopの代わりに次を実行
# git stash pop --index   # ステージの状態まで戻す

見落としやすいのは、git stash pop が既定ではステージの状態まで再現しない点です。Git 2.50.1 の出力例では、git add 済みだった既存ファイルの変更と削除は未ステージに戻り、新規追加ファイルだけがステージ済みで戻りました。git stash の公式ドキュメントのとおり、ステージまで戻すには --index を付けるか、設定 stash.index を true にします。不要になった stash の削除と、誤って消した stash の復元は「git stashの削除：drop・clearの使い分けと消したstashの復元手順」を参照してください。

トラブル別の逆引き：エラーメッセージから引くGitコマンド

画面に出たメッセージから次に打つコマンドを引けます。どの場合も、先に git status でマージ中・rebase 中かを確かめてください。

コンフリクトの読み方と予防の設計は「コンフリクトとは？Gitで変更が衝突する仕組みと解消手順」で詳しく扱っています。

reset・rebase後のコミット復元とreflogによる復元先の確認

git reset --hard や rebase の失敗でコミットが消えたように見えても、コミット自体はしばらくリポジトリに残っています。git reflog は HEAD が動いた履歴を記録しているので、戻したい時点の番号を探して reset します。

$ git reflog
216474b HEAD@{0}: commit (amend): c1x
0bd9af0 HEAD@{1}: reset: moving to HEAD~1
bdf2e95 HEAD@{2}: commit: a2      ← reset で消えたコミット
$ git reset --hard HEAD@{2}

直前の reset・merge・rebase の前に戻すだけなら、Git がその直前の HEAD を記録している git reset --hard ORIG_HEAD でも戻せます。ただし ORIG_HEAD は次の reset や merge で上書きされるので、間に別の操作を挟んだら reflog を使います。reflog はローカルにしか無く、git clone し直したリポジトリには残っていません。消したと気づいたら、同じ作業ディレクトリで早めに戻してください。

確認・調査のコマンド（show・blame・tag・cherry-pick）

git show <hash>                 # コミットの差分とメッセージ
git blame -L 10,20 app.js       # 10〜20行目の最終変更コミット
git tag -a v1.2.0 -m "v1.2.0"   # 注釈付きタグ
git push origin v1.2.0          # タグは明示的に push する
git cherry-pick <hash>          # 別ブランチの特定コミットだけを取り込む

既定の設定では、タグは git push だけでは送られません。リリースのタグを付けたら名前を指定して push するか、設定 push.followTags を true にして、push するコミットに付いた注釈付きタグを一緒に送ります。cherry-pick は同じ変更を別IDのコミットとして複製するので、修正をリリースブランチへ移すなど、必要な変更だけを選んで取り込む場合に使います。

Git Bashで使う基本コマンドとオプションの調べ方

Windows で Git を入れると付いてくる Git Bash は、Git for Windows が同梱する Bash 環境です。git コマンドに加えて、Linux や macOS と同じ基本的なシェルコマンドが使えます。Git の操作で一緒に打つことが多いのは次のものです。

Cドライブは /c/ のように表記されます（cd /c/Users）。インストール手順と更新方法は「Git for Windowsの最新版は2.56.0｜ダウンロード・インストール手順と更新方法」にまとめました。Gitのオプション一覧は、先に触れた git <コマンド> -h で確かめるのが早く、手元の版で使えるオプションだけが表示されます。GitHub のプルリクエストや Issue までターミナルで扱うなら、「ghコマンド（GitHub CLI）とは？」で紹介している GitHub CLI を併用します。

よくある質問

Gitコマンドとは何ですか？

Gitの機能をターミナル（コマンドライン）から呼び出す命令です。git の後にサブコマンド（commit・push など）とオプションを続けて書きます。エラーの意味や取り消し方はコマンド名で調べることになるため、GUI派でも基本の20個前後は役割を知っておくと困りません。

Gitでよく使うコマンドは何ですか？

日常の作業で毎日のように打つのは、git status・git add・git commit・git switch・git pull・git push・git log・git diff の8つです。これに、取り消しの git restore・git reset・git revert、退避の git stash、ブランチ統合の git merge を加えると、チーム開発の大半の場面に対応できます。

Gitのオプション一覧はどこで確認できますか？

手元で git <コマンド> -h を実行すると、そのコマンドのオプションが短い説明つきで一覧表示されます。詳しい説明は git help <コマンド> か、公式サイトの git-scm.com/docs で読めます。Webの解説記事は書かれた時点の版のものなので、オプションの有無は手元の版のマニュアルで確認してください。-h は要約なので、表示されないオプションもあります。

Gitのバージョンはどう確認しますか？

git --version を実行すると、git version 2.56.0 のように表示されます。2026年10月時点の最新版は 2.56.0（2026年9月28日公開）です。macOS 付属の Git は (Apple Git-155) のように Apple の版番号が付き、最新版より遅れることがあります。更新方法は「Gitの最新バージョンは2.56.0」の記事で OS 別に解説しています。

git pull は使わない方がよいのですか？

使って問題ありません。「使うな」と言われる理由は、設定によっては意図しないマージコミットを作ったり、分岐時に止まったりするためです。統合方式を pull.rebase true か pull.ff only に決めておけば挙動は予測できます。慎重に進めたい場面では、git fetch で取得してから git log --oneline HEAD..origin/main で差分を見て、統合を自分で行う方法もあります。

関連記事

• Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点【2026年10月】
• git rebaseとは？使い方・mergeとの違い・コンフリクト解決とやり直しを解説
• git mergeの取り消し｜abort・reset・revert -mの使い分け
• git stashの削除：drop・clearの使い分けと消したstashの復元手順
• コンフリクトとは？Gitで変更が衝突する仕組みと解消手順・予防設計を実装視点で解説