Gitコマンドのチートシート

実務で頻出するGitコマンドのチートシートです。ブランチの作成から、作業中の変更の退避、コミットの修正方法までをまとめています。

1. 初期設定 (Config)

アカウントを使い分ける際の設定です。

# 設定の確認
git config --global -l  # グローバル設定（全てのリポジトリで共通）
git config --local -l   # ローカル設定（このリポジトリだけで有効）

# デフォルトのエディタを VS Code に設定する
git config --global core.editor "code --wait"

# ユーザー名とメールアドレスの設定（グローバル）
git config --global user.name "indigo165e83"
git config --global user.email "indigo165e833@gmail.com"

# ユーザー名とメールアドレスの設定（ローカル）
# 別のアカウントを使いたいリポジトリのディレクトリに移動して、--local 設定を行う
git config --local user.name "foo"
git config --local user.email "foo@example.com"

2. ブランチの作成・切り替え・削除

mainなどのベースとなるブランチを最新にしてから作成するのが基本です。

ブランチの確認

# ローカルブランチの確認
git branch

# リモートブランチも含めて確認
git branch -a

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

# ベースブランチを最新にする
git switch main
git pull origin main

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

# リモートへプッシュして紐付け
git push -u origin new-feature-branch

ブランチ名の変更

ローカルで名前を変えてから、リモートの古いブランチを削除して新しいものをプッシュします。

# ローカルの名前変更
git branch -m 旧ブランチ名 新ブランチ名

# リモートの旧ブランチを削除し、新ブランチをプッシュ
git push origin --delete 旧ブランチ名
git push -u origin 新ブランチ名

ブランチの削除

# ローカル削除（-D は強制削除）
git branch -D release/2026-January-2nd

# リモート削除
git push origin --delete release/2026-January-2nd

3. 変更の記録とPR作成 (add / commit / push)

ブランチで作業した変更をリモートに反映し、PR（プルリクエスト）を作成するまでの流れです。

ステージングエリアとは

Git には「ステージングエリア」という中間エリアがあります。git add で変更をステージングエリアに移してから、git commit でコミットするという2段階の仕組みになっています。

作業ファイル  ──git add──→  ステージングエリア  ──git commit──→  ローカルリポジトリ  ──git push──→  リモート (GitHub)

コマンド

# 現在の状態を確認（どのファイルが変更・未追跡かを表示）
git status

# 特定のファイルをステージング
git add [ファイルパス]

# 変更があるファイルを全てステージング
git add .

# ステージングした内容をコミット
git commit -m "コミットメッセージ"

# リモートにプッシュ（-u で追跡設定も同時に行う）
git push -u origin [ブランチ名]

# 2回目以降のプッシュ（追跡設定済みの場合は省略形でOK）
git push

コミットメッセージの書き方

変更の「何を」ではなく「なぜ・何のために」を簡潔に書くのが基本です。

# 良い例
git commit -m "ログイン画面のバリデーションエラーメッセージを修正"
git commit -m "ユーザー一覧APIにページネーションを追加"

# 避けたい例（何をしたかだけで、目的が分からない）
git commit -m "修正"
git commit -m "update"

PR（プルリクエスト）の作成

プッシュ後、GitHubでPRを作成します。

1. GitHub でリポジトリを開く。
2. 画面上部に表示される「Compare & pull request」ボタンをクリック。
3. base（取り込み先）と compare（自分のブランチ）が正しいことを確認する。
4. タイトルと説明を記入して「Create pull request」をクリック。

Tip

PRの説明欄には「何を・なぜ変更したか」と「動作確認の手順」を書くと、レビュアーがスムーズに確認できます。

4. リモートとの同期

用語の整理

origin（オリジン）

GitHubなどのリモートリポジトリにつけた「あだ名」です。git clone すると自動的に origin という名前がつきます。origin/main は「origin というリモートの main ブランチ」を意味します。

追跡ブランチ（トラッキングブランチ）

リモートブランチの状態をローカルに記録したコピーです。origin/main や origin/feature/xxx のような形式で参照します。git fetch を実行すると更新されますが、自分の作業ファイルには影響しません。

リモート (GitHub)
  origin/main
      │
      │  git fetch（追跡ブランチを更新、作業ファイルは変わらない）
      ▼
ローカルの追跡ブランチ
  origin/main
      │
      │  git merge（作業ブランチに取り込む）
      ▼
ローカルの作業ブランチ
  main

fetch と merge の使い分け

コマンド	何をするか
git fetch	リモートの情報を取得して追跡ブランチだけを更新する。作業ファイルは変わらない。
git merge	別ブランチの変更を現在の作業ブランチに取り込む。
git pull	git fetch + git merge をまとめて行うショートカット。

git fetch だけ実行した時点では、まだ自分のブランチには何も反映されません。内容を確認してから git merge で取り込む、という2ステップの流れが安全です。

コマンド

# リモートの情報を最新にする（削除済みブランチの整理も含む）
git fetch --all --prune

• --all : 登録されている全てのリモート（通常は origin のみ）から取得する。
• --prune : リモートで削除済みのブランチを、追跡ブランチからも削除して整理する。

# 追跡ブランチの内容を現在のブランチに取り込む
git merge origin/main

# リモートブランチをローカルにチェックアウト（ローカル名とリモート名が異なる場合）
git switch -c [ローカル名] origin/[リモート名]

# 同名のリモートブランチが存在する場合は省略形が使える（実務ではこちらが一般的）
# 例: origin/feature/login → ローカルの feature/login を作成して追跡設定も自動でされる
git switch feature/login

5. リリース・マージフロー

履歴を分かりやすく残すために --no-ff オプションを使用します。

# マージの実行（マージコミットを必ず作成）
git merge --no-ff origin/feature/xxx

• --no-ff : Fast-Forward（早送り）をせず、合流したという証拠を履歴に残します。

6. 履歴の確認 (log)

コミット履歴を見やすく確認するためのコマンドです。

# シンプルな一覧表示
git log --oneline

# ブランチの分岐・合流をグラフで確認
git log --oneline --graph --decorate

# 件数を絞って確認（直近5件）
git log --oneline -5

# 特定ファイルの変更履歴
git log --oneline -- [ファイルパス]

7. 作業中の変更を一時退避する (stash)

別のブランチへ切り替えたいが、今の作業（編集中のファイルなど）をコミットしたくない場合に使用します。

# 編集中のファイルを一時退避
git stash

# 新しく作成した（Untracked）ファイルも含めて退避する場合
git stash -u

# 名前をつけて退避する（複数の stash を管理しやすくなる）
git stash push -m "作業内容のメモ"

# 退避した作業の一覧を確認
git stash list

# 退避した作業を復元する（一覧の先頭 stash@{0} を適用して削除）
git stash pop

# 特定の stash を指定して復元する
git stash pop stash@{1}

# 復元せずに削除する
git stash drop stash@{0}

8. コミットの取り消し (reset)

ローカルのコミットを取り消す方法です。Push 済みのコミットへの使用は避けてください。

# 直前のコミットを取り消す（変更内容はステージングに残す）
git reset --soft HEAD~1

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

# 直前のコミットを取り消す（変更内容ごと完全に破棄）
git reset --hard HEAD~1

オプション	コミット	ステージング	ファイルの変更
--soft	取り消す	残る	残る
（なし）	取り消す	取り消す	残る
--hard	取り消す	取り消す	破棄

Caution

--hard は変更内容が完全に消えます。実行前に内容を確認してください。

9. 直前のコミットに修正を追加する (amend)

直前のコミットに修正を追加する方法です。

まだ Push していない場合

コミットが自分のPC内（ローカル）だけにしかない場合

1. 漏れていた修正を行い、保存する。
2. 修正したファイルをステージング（add）する。

git add .

3. 直前のコミットに合流させる。

git commit --amend --no-edit

• --amend : 直前のコミットをやり直す。
• --no-edit : コミットメッセージを変更せずにそのまま使う。

すでに Push してしまった場合（注意が必要）

GitHubなどのリモートサーバーに一度 Push してしまったコミットを修正する場合、「サーバー上の歴史を無理やり書き換える」 ことになります。

1. 上記と同じ手順でローカルのコミットを修正する。
2. 強制的に Push（Force Push）する。

git push --force-with-lease origin [現在のブランチ名]

• --force-with-lease : 自分が知らない間に他の人がプッシュしていた場合は上書きを拒否する、安全な強制プッシュ。-f より推奨。

Caution

チーム開発での注意点 共有ブランチ（main や develop など）でこれを行うと、他のメンバーの履歴と整合性が取れなくなり、混乱を招く可能性があります。 「自分一人で作業しているブランチ」 か、「PR（プルリクエスト）を出した直後で、まだ誰もレビューを始めていない」 状態の時にだけ行うのが安全です。