Git で最後のコミットを修正する方法 (メッセージ、ファイル、作成者、および元に戻す)

現在のブランチの最新のコミットを修正するには、git commit --amend を実行します。何もステージングされていない場合、Git はコミットを更新されたメッセージに置き換えます。最初に新しい変更をステージングすると、Git はそれらのステージングされた変更をコミットに組み込み、既存のメッセージを --no-edit で保持するか、所定の位置に書き換えることができます。視覚的なワークフローをお好みですか? macOS、Windows、および Linux の GitTree で、コミット パネルの 前のコミットの修正 をオンにして (または、グラフの一番上のコミットを右クリックして コミット メッセージの編集… を選択)、メッセージを事前入力し、個々の行をステージングまたはステージング解除し、プッシュされた履歴を書き換える前にリモート ブランチの警告を表示し、ワンクリックの 元に戻すでいつでも復元できます。

クイックリファレンス: すべての git commit --amend コマンド

最新のコミットの問題点に一致するコマンドを正確に選択してください。または、エッジ ケース、フック、署名付きコミット、および視覚的な代替案については、以下の詳細セクションに移動してください。

git commit --amend が内部で実際に行うこと

すべての Git コミット ハッシュは、ルート ツリー スナップショット、親 コミット ハッシュ、作成者 名/電子メール/タイムスタンプ、コミッター 名/電子メール/タイムスタンプ、コミット メッセージ の 5 つのデータから計算された暗号化チェックサム (SHA-1 または SHA-256) です。メッセージ内の 1 文字でも、または 1 秒後のコミッターのタイムスタンプを変更すると、結果のハッシュはまったく異なります。

# Before git commit --amend:
A --- B --- C  <-- main (HEAD)

# After git commit --amend:
A --- B --- C' <-- main (HEAD)
       \
        C      (still in git reflog as HEAD@{1} until garbage collection)

git commit --amend を実行すると、Git は ステージング領域 (インデックス) に現在あるものをすべて取得し、それを C (B) の親ポインターと組み合わせて、新しいコミット オブジェクト C' を書き込み、C' を指すように現在のブランチ参照を更新します。元のコミット C はすぐには削除されません。ローカルの reflog (HEAD@{1}) に少なくとも 30 ～ 90 日間 (gc.reflogExpireUnreachable) 記録されたままになります。そのため、誤って修正した場合でも、git reflog または GitTree の 元に戻すとやり直し および 紛失と発見 ツールを使用して常にローカルで回復できます。

1.最後のコミットメッセージを変更する

コミットしたばかりで、タイプミス、間違った Jira/GitHub 問題番号、または Conventional Commits プレフィックス (feat:、fix:、chore:) の欠落にすぐに気づいた場合は、まず git status をチェックして、何かがステージングされているかどうかを確認してください。

-m を使用して、新しい 1 行または複数段落のメッセージを渡します

エディタを起動せずにターミナルからメッセージを直接置き換えるには、-m を渡します。複数の -m フラグを連結して件名と本文の段落を作成できます。

# Replace the commit subject inline
git commit --amend -m "fix(auth): validate refresh token expiry before rotation"

# Replace both the subject line and body paragraph
git commit --amend \
  -m "fix(auth): validate refresh token expiry before rotation" \
  -m "Prevents expired tokens from issuing a new session when clock skew exceeds 30s."

テキストエディタで既存のメッセージを編集します

コミットに既に詳細な複数行の説明、トレーラー (Co-authored-by:、Signed-off-by:)、または再入力したくない問題の参照が含まれている場合は、-m を指定せずに git commit --amend を実行します。

git commit --amend

Git は、現在のコミット メッセージがプリロードされた状態で、構成済みの core.editor (Vim、Nano、VS Code、Zed など) を開きます。ファイルを保存して閉じて、修正されたコミットを書き込みます。エディターを開いている間に気が変わった場合は、コミット メッセージ全体を削除して (ファイルを空のままにし)、保存します。Git は Aborting commit due to empty commit message で修正を中止し、HEAD はそのまま残します。

2.忘れられたファイルまたは特定の行を最後のコミットに追加します

開発者が --amend に到達する最も一般的な理由は、コミットする前に 1 つのファイルの保存、テスト フィクスチャのステージング、またはフォーマッタの実行を忘れることです。最初に不足している変更をステージングし、次に --no-edit で修正することで、Git がエディターを開かずに既存のコミット メッセージを保持します。

# Stage the forgotten file (or files)
git add src/auth/token-validator.test.ts

# Fold the staged file into the last commit and keep the existing message
git commit --amend --no-edit

修正する前に特定の行またはハンクのみをステージングする

作業ツリーに、前のコミットに属する 3 行の修正と * 40 行のデバッグ ログまたは次の機能の作業の両方が含まれている場合はどうなるでしょうか? git add . または git commit -a --amend を実行しないでください。代わりに、パッチ モードを使用して、前のコミットに属する正確なハンクまたは行のみをステージングします (git add -p とステージング特定行のガイド で詳しく説明されています)。

# Choose y/n/s (split) for each changed hunk
git add -p src/auth/token-validator.ts

# Verify what is staged vs what stays in the working tree
git diff --staged

# Amend the last commit with only the staged hunks
git commit --amend --no-edit

GitTree では、これを行うためにターミナル ハンクの分割 (s、e) と格闘する必要はありません。ステージングされていない変更 内の任意のファイルをクリックし、正確な行を選択するか、サイドバイサイドまたはインラインの差分で Stage Hunk をクリックし、前のコミットの修正 を切り替えます。 Git diff ガイド を参照して、ステージングされた差分とステージングされていない差分を検査することで、修正されたコミットに誤ってコードが紛れ込むことをどのように防ぐかを確認してください。

3. 誤ってコミットしたファイルを削除します (ディスクから削除せずに)

git add . を実行し、誤って .env.local ファイル、大規模なビルド アーティファクト、または別の pull リクエストに属するファイルをコミットしたとします。 HEAD からファイルを削除する方法は、ファイルが HEAD (HEAD~1) より前のコミットに存在していたのか、または HEAD に新しく追加されたのかによって異なります。

ケース A: 新しく追加されたファイルを最後のコミットから削除する (ローカル ファイルを保持する)

git rm --cached を使用して、物理ファイルをディスク上に残したままステージング インデックスからファイルを削除し、次のように修正します。

# Remove the file from the index only (leaves the file on disk)
git rm --cached .env.local

# Optional: add it to .gitignore so it never gets staged again
echo ".env.local" >> .gitignore
git add .gitignore

# Rewrite the last commit without .env.local
git commit --amend --no-edit

ケース B: 最後のコミットで追跡されたファイルへの編集を元に戻す (ローカル編集を保持する)

<file> がすでに HEAD~1 で追跡されており、その編集内容を誤って HEAD に含めた場合は、git rm --cached を使用しないでください (ファイルの削除が HEAD に記録されることになります!)。代わりに、そのファイルのインデックス エントリを HEAD~1 から復元します。

# Reset only the staged index state of <file> back to HEAD~1
git restore --source=HEAD~1 --staged src/config/database.ts

# Amend HEAD: the commit no longer touches database.ts, and your local edits stay in the working tree
git commit --amend --no-edit

不要なローカル編集を破棄したり、追跡されていないファイルを完全に消去したい場合は、Git で変更を破棄し、追跡されていないファイルを消去する方法 と Git で削除されたファイルを復元する方法 を参照してください。

4. 最後のコミットの作成者、電子メール、またはタイムスタンプを変更する

user.email を設定する前に新しいラップトップでコミットするか、個人用の GitHub メールがグローバルに構成されているときに作業リポジトリ内でコミットすると、コミットによって間違った ID が記録されます。 git commit --amend は、ファイルに一切触れずにコミットのメタデータを書き換えることができます。

# Option 1: Set an explicit author name and email on the last commit
git commit --amend --author="Jane Doe <jane@company.com>" --no-edit

# Option 2: Update git config first, then reset the commit author to match
git config user.name "Jane Doe"
git config user.email "jane@company.com"
git commit --amend --reset-author --no-edit

# Option 3: Amend the author date as well
git commit --amend --date="2026-11-11T14:30:00+02:00" --no-edit

5. すでにプッシュしたコミットを安全に修正する方法

すでに origin にプッシュされているコミットを修正すると、ローカル ブランチとリモート追跡ブランチ (origin/<branch>) 分岐: ローカル ブランチには C' がありますが、origin にはまだ C があります。どちらのコミットも親 B を共有します。

ブランチが 独自の機能またはプルリクエスト ブランチの場合は、--force-with-lease (Git 2.30 以降では --force-if-includes) を使用してリモートを安全に更新します。

# Safely replace the remote branch tip with your amended commit
git push --force-with-lease --force-if-includes origin HEAD

• `--force` ではなく `--force-with-lease` を使用する理由: プレーンの git push --force はリモート ブランチを盲目的に上書きし、最後のフェッチ以降にチームメイトまたは CI ボットがプッシュしたコミットをすべて消去します。 --force-with-lease は、origin/<branch> がローカルのリモート追跡参照に保存されている正確なコミット SHA をまだ指していることを確認します。その間に他の誰かがプッシュした場合、Git はその作業を失う代わりにプッシュを拒否します。
• `--force-if-includes` の追加内容: バックグラウンドの自動取得が有効になっている場合、プッシュする前にリモート追跡参照が更新される可能性があります。 --force-if-includes は、書き換えを許可する前に、リモート ブランチの先端のコミットが実際にローカル reflog に統合されたことを検証します。
• `main` または共有ブランチを使用している場合: 他の開発者が作業の基礎としている共有ブランチを修正したり強制プッシュしたりしないでください。代わりに、コミットをそのままにして新しい修正コミットをプッシュするか、git revert で完全に取り消します (コミットとマージを元に戻すガイド と プッシュされたミスを回復するチュートリアル を参照してください)。
• 最初に追跡ブランチを設定する必要がありますか? Git でアップストリーム ブランチを設定する方法 を参照してください。

6. 修正する必要があるコミットが最後のコミットではない場合はどうすればよいですか?

git commit --amend は HEAD (チップコミット) のみを書き換えます。タイプミスまたは欠落した変更が HEAD~2 または 3 つのコミットに属する場合、手動で隠したりチェリーピッキングしたりすることなく、クリーンなオプションが 2 つあります。

オプション 1: git commit --fixup を使用した高速 CLI 自動スカッシュ

修正をステージングし、古いコミットの SHA を対象とする --fixup コミットを作成し (またはメッセージを編集する場合は --fixup=amend:<sha>)、git rebase -i --autosquash を実行します。

# 1. Stage the changes meant for the older commit (e.g. a1b2c3d)
git add src/api/client.ts

# 2. Create a fixup commit targeting a1b2c3d
git commit --fixup=a1b2c3d

# 3. Autosquash the fixup commit straight into a1b2c3d
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash a1b2c3d~1

オプション 2: GitTree での視覚的な対話型リベース

ターミナルで SHA をコピーしてリベース Todo ファイルを編集する代わりに、完全な インタラクティブ リベース GUI ガイド と ブランチ リベース ガイド をお読みください。 GitTree の インタラクティブ リベース および リワード、スカッシュ アンド ドロップ プランナーで、グラフ内の古いコミットを右クリックし、ここからインタラクティブ リベース… を選択し、そのコミットを リワードに切り替えるか、修正コミットを修正/スカッシュにドラッグして、ワンクリックで適用します。

7. 誤って git commit --amend を元に戻す方法

意図しないファイルがステージングされている間に git commit --amend を実行しましたか? それとも必要なコミット メッセージを誤って上書きしましたか? Git は HEAD のすべての動きをローカル reflog に記録するため、修正前のコミットはまだ HEAD@{1} に安全に保管されています。

# 1. Inspect the reflog to see the amend and the commit before it
git reflog -n 5
# e9f8d7c (HEAD -> feature) HEAD@{0}: commit (amend): feat: add billing webhook
# 4a3b2c1 HEAD@{1}: commit: feat: add billing webhook

# 2. Restore the branch to the pre-amend commit and keep any extra changes staged
git reset --soft HEAD@{1}

git reset --soft HEAD@{1} を使用すると、ブランチ ポインタが元のコミット (4a3b2c1) に戻り、修正されたコミットとインデックスにステージングされた元のコミットの差が残ります。作業ツリー内の何も失われません。 soft、mixed、および hard のリセットと reflog のリカバリについて詳しくは、Gitリセット --soft vs --mixed vs --hard、reflog を使用して git リセット、リベース、またはコミットを元に戻す方法、および 削除されたスタッシュと未解決のコミットを回復する方法 を参照してください。

git commit --amend を使用する場合と、reset、revert、または rebase -i を使用する場合

履歴を修正する必要があるときは常にこの決定マトリックスを使用して、コミットの位置とチームメイトがそれをプルしたかどうかに一致するコマンドを選択します。

GitTree がよくある git commit --amend の間違いをすべて排除する方法

コマンドラインによる修正事故のほとんどは、手遅れになるまでターミナルが 3 つの重要なコンテキスト部分を隠すために発生します。つまり、ステージング領域にすでに存在するもの、HEAD がすでに origin にプッシュされているかどうか、上書きする前のコミット SHA の内容です。 GitTree は、これらの各障害モードをインターフェースで直接解決します。

• ステージングされたファイルとステージングされていないライブの差分検査: [コミットの修正] をクリックする前に、ステージングされた変更 リストがコミット ボックスのすぐ上に表示されるため、中途半端なファイルを誤って HEAD に折りたたむことがなくなります。ワンクリックで個々のライン、ハンク、ファイルをステージングまたはステージング解除できます (ファイル、ハンク、ラインのステージング)。
• プッシュされたコミットの検出とリース付き強制プッシュ保護: HEAD がすでにリモート ブランチ上にある場合、GitTree は修正する前にコミット パネル内で警告を発し、ワークフローを 強制プッシュ (リース付き)… と組み合わせて、チームメイトのプッシュが上書きされないようにします。
• 右クリックによる書き換えと `fixup!` / `amend!` のクイック作成: ステージングされたファイルに手を加えずに HEAD を書き換えたいですか? コミット グラフ の一番上のコミットを右クリックし、コミット メッセージの編集… を選択します。古いコミットを修正する必要がありますか?グラフ内の古いコミットを右クリックして、fixup! または amend! コミットを作成するか、対話型リベース を開きます。
• 自動安全スナップショット (`refs/ogt/trash`) とワンクリックで元に戻す: コミットの修正、対話型リベース、リセット、ブランチ削除、破棄を含む 19 の履歴変更操作を実行する前に、GitTree は refs/ogt/trash にローカル スナップショットを記録します。 元に戻す (Cmd+Z / Ctrl+Z) をクリックすると、修正前の正確なコミットとステージングの状態がすぐに復元されます。
• ビジュアル遺失物と組み込みターミナル: 組み込みターミナル または数週間前に修正した場合でも、遺失物 は到達不能なコミットを表示し、完全な差分で置き換えられるため、生の git reflog 出力を解析せずにコミットを復元、チェリーピック、または分岐できます。
• Git フック、シークレット警告、AI コミット メッセージ: GitTree はリポジトリの pre-commit と commit-msg Git フック を実行し、偶発的な API キーがないかステージングされた差分をチェックし、(GitTree Pro では) 独自のローカル コーディング エージェントを使用して Nour に正確なコミット メッセージを生成させます。