git add・commitの使い方｜addの取り消しと–amendまで

git add は「次のコミットに入れる変更を選ぶ」コマンド、git commit は「選んだ変更を履歴として記録する」コマンドです。 取り消したいときは、add なら git restore --staged <ファイル>、直前の commit なら git commit --amend を使います。この3つを押さえると、日々の記録作業のほとんどをまかなえます。

この記事では、add → commit → やり直しを1本の流れとして追いかけ、各段階の git status と git log の出力を実際に動かした結果のまま載せています（Git 2.43.0、メッセージは英語表示）。「初回コミットの前だけ restore --staged がエラーになる」「push した後の --amend が rejected になる」といった、つまずきやすい場面も再現しました。コマンドはそのまま貼って試せる形にしてあります。

git add・commit・やり直しの早見表

まずは「やりたいこと」からコマンドを引ける表です。迷ったらこの表だけ見れば用が足ります。

3つの場所を先に理解する（作業ツリー・ステージ・リポジトリ）

add と commit の動きは、変更が置かれる3つの場所を知るとすっきり整理できます。

流れを図にすると次のとおりです。

flowchart LR
    A[作業ツリー] -- git add --> B[ステージ]
    B -- git commit --> C[リポジトリ]
    B -- git restore --staged --> A
    C -- git commit --amend --> C

add と commit が分かれているのは、「編集した変更のうち、今回記録するものだけを選べる」ようにするためです。 3つのファイルを触っていても、関係のある2つだけを先にコミットし、残りは次のコミットに回せます。履歴が「意味のあるまとまり」になり、後から読み返しやすくなります。

最初のコミットまでを通しで動かす

ここからは実際のコマンドと出力です。次の準備をすると、同じ結果を手元で再現できます。

mkdir memo && cd memo
git init
printf 'line1\n' > readme.txt
printf 'key=1\n' > secret.env

git init の出力は次のとおりです（パスは環境によって変わります）。

Initialized empty Git repository in /home/taro/memo/.git/

git status で現在地を確認する

作業の前後で git status を打つ習慣をつけると、いまどの場所に何があるかを常に把握できます。

git status

On branch main

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    readme.txt
    secret.env

nothing added to commit but untracked files present (use "git add" to track)

Untracked files は「Git がまだ管理していないファイル」です。出力のかっこ内に、次に使うコマンドのヒントが書かれています。

git add でステージに載せる

git add readme.txt secret.env
git status

On branch main

No commits yet

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
    new file:   readme.txt
    new file:   secret.env

Changes to be committed（コミットされる変更）に2つのファイルが移りました。git add 自体は成功しても何も表示しません。

初回コミット前に add を取り消す（git rm --cached）

ここで secret.env はコミットしたくないファイルだったと気づいたとします。よく紹介される git restore --staged を試すと、初回コミット前に限ってエラーになります。

git restore --staged secret.env

fatal: could not resolve HEAD

restore --staged は「ステージの内容を HEAD（最新のコミット）の状態に戻す」コマンドです。まだコミットが1つもないので、戻し先の HEAD が見つからないというわけです。この場面では、git status のヒントに出ていた git rm --cached を使います。

git rm --cached secret.env
git status --short

rm 'secret.env'
A  readme.txt
?? secret.env

rm と表示されますが、--cached を付けているのでファイル本体は残ります（ステージからだけ外れます）。git status --short は状態を2文字で表す短縮表示で、A はステージ済みの新規ファイル、?? は未追跡を表します。なお、初回コミット前でも git reset -- secret.env でステージから外せることを確認しました。

git commit で記録する

git commit -m "最初のコミット"

[main (root-commit) 61eb25a] 最初のコミット
 1 file changed, 1 insertion(+)
 create mode 100644 readme.txt

git log --oneline

61eb25a 最初のコミット

61eb25a がコミットの ID（ハッシュの先頭7文字）です。(root-commit) は「このリポジトリで最初のコミット」という意味で、2回目以降は表示されません。

2回目以降のコミット：add の取り消しは restore --staged

続けて、既存ファイルの変更と新規ファイルを混ぜた状態を作ります。

printf 'line2\n' >> readme.txt
printf 'todo\n' > todo.txt
printf 'x\n' > draft.txt
git status

On branch main
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    modified:   readme.txt

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    draft.txt
    secret.env
    todo.txt

no changes added to commit (use "git add" and/or "git commit -a")

今度は Changes not staged for commit（追跡済みだが add していない変更）と Untracked files の2つに分かれて表示されます。3つを add してみます。

git add readme.txt todo.txt draft.txt
git status --short

A  draft.txt
M  readme.txt
A  todo.txt
?? secret.env

restore --staged で1ファイルだけステージから外す

draft.txt はまだ書きかけなので、今回のコミットから外します。コミットが1つ以上ある状態では、git restore --staged が素直に動きます。

git restore --staged draft.txt
git status --short

M  readme.txt
A  todo.txt
?? draft.txt
?? secret.env

draft.txt が A（ステージ済み）から ??（未追跡）に戻りました。ファイルの中身は変わっていません。

reset でも同じ結果になる

git reset でも同じことができます。もう一度 add してから試した結果です。

git add draft.txt
git reset HEAD draft.txt
git status --short

M  readme.txt
A  todo.txt
?? draft.txt
?? secret.env

git reset -- draft.txt と書いても結果は同じでした。

add を取り消すコマンドの違い

選び方の目安は「コミットがあるなら restore --staged、初回コミット前なら rm --cached」です。 表の最後の行は名前が似ているので気をつけたいところです。--staged を付け忘れると、作業ツリーの編集内容を元に戻す動きになります。add だけを取り消したいときは、--staged が付いていることを確認してから実行すると安心です。

もう1つ、git rm --cached をすでにコミット済みのファイルに使うと「Git の管理から外す」という意味になり、次のコミットにファイルの削除が含まれます。新しく add したばかりのファイルに使うぶんには、add の取り消しと同じ結果になります。

git commit の使い方とメッセージの書き方

ステージに readme.txt と todo.txt が載った状態でコミットします。わざとメッセージを打ち間違えてみます。

git commit -m "todoを追加しt"
git log --oneline

[main ad8629a] todoを追加しt
 2 files changed, 2 insertions(+)
 create mode 100644 todo.txt

ad8629a todoを追加しt
61eb25a 最初のコミット

commit の主なオプション

ステージが空のまま commit するとどうなるか

add を忘れて commit すると、コミットは作られず、状況の説明が表示されます。

git commit -m "none"

On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
    secret.env

nothing added to commit but untracked files present (use "git add" to track)

nothing added to commit と出たら、add がまだという合図です。 git status で対象を確認し、add してからもう一度 commit します。

読みやすいコミットメッセージの型

「修正」「更新」だけよりも、「一覧画面の並び順を作成日の降順に変更」のように対象と内容を書くと、後から git log を読む人（未来の自分を含む）が助かります。

直前のコミットをやり直す（git commit --amend）

--amend は「直前のコミットを、新しいコミットで置き換える」オプションです。使い方は目的によって2通りあります。

メッセージだけ直す（--amend -m）

先ほどの打ち間違い「追加しt」を直します。

git commit --amend -m "todoを追加した"
git log --oneline

[main 47f66c0] todoを追加した
 Date: Sat Oct 3 04:21:49 2026 +0900
 2 files changed, 2 insertions(+)
 create mode 100644 todo.txt

47f66c0 todoを追加した
61eb25a 最初のコミット

注目したいのは、コミット ID が ad8629a から 47f66c0 に変わっている点です。amend は元のコミットを書き換えるのではなく、内容を引き継いだ新しいコミットを作って差し替えます。コミット数は2つのまま増えていません。Date: の行は、元のコミットの作成日時（Author Date）が引き継がれたことを示しています。

-m を付けずに git commit --amend とだけ打つと、エディタが開いて直前のメッセージを編集できます。

書式の注意：-m を省くとエラーになる

--amend の直後にメッセージを直接書くと、Git はそれをファイル名として解釈します。

git commit --amend "x"

error: pathspec 'x' did not match any file(s) known to git

メッセージを指定するときは、--amend -m "メッセージ" のように必ず -m をはさみます。

ファイルを足す（--amend --no-edit）

コミットした後で「draft.txt も一緒に入れるつもりだった」と気づいた場合です。足したいファイルを add してから、--no-edit（メッセージはそのまま）を付けて amend します。

git add draft.txt
git commit --amend --no-edit
git log --oneline --stat

[main c8c27e2] todoを追加した
 Date: Sat Oct 3 04:21:49 2026 +0900
 3 files changed, 3 insertions(+)
 create mode 100644 draft.txt
 create mode 100644 todo.txt

c8c27e2 todoを追加した
 draft.txt  | 1 +
 readme.txt | 1 +
 todo.txt   | 1 +
 3 files changed, 3 insertions(+)
61eb25a 最初のコミット
 readme.txt | 1 +
 1 file changed, 1 insertion(+)

2 files changed が 3 files changed に増え、同じメッセージのまま draft.txt が加わりました。逆に、コミットから1ファイルだけ外したいときは次の手順です。

git restore --source=HEAD~1 --staged draft.txt   # ステージを1つ前のコミットの状態に戻す
git commit --amend --no-edit                      # 直前のコミットを作り直す

（この「外す」手順は今回は未実行です。新規ファイルの場合は git rm --cached draft.txt の後に amend する方法もあります。）

amend の使い分け表

amend が扱えるのは「直前の1つ」だけです。もっと前のコミットを直すときは、対話的リベース（git rebase -i）の出番になります。

amend を取り消したいとき

amend で置き換えられた元のコミットは、すぐに消えるわけではありません。git reflog に HEAD の移動履歴が残っています。

git reflog -5

c84eb08 HEAD@{0}: commit (amend): todoとdraftを追加した
c8c27e2 HEAD@{1}: commit (amend): todoを追加した
47f66c0 HEAD@{2}: commit (amend): todoを追加した
ad8629a HEAD@{3}: commit: todoを追加しt
61eb25a HEAD@{4}: commit (initial): 最初のコミット

（この出力は、次の章の amend まで終えた時点のものです。）1つ前の状態に戻すなら git reset --soft HEAD@{1} で、amend 前のコミットに HEAD を戻せます。--soft なので、ファイルとステージの内容は保たれます。

push した後に amend すると rejected になる理由

ここまでの amend は、まだ push していないコミットが相手でした。push 済みのコミットを amend すると、次の push が rejected（拒否）になります。 再現してみます。

git init --bare ../remote.git          # 練習用のリモートを用意
git remote add origin ../remote.git
git push -u origin main

To ../remote.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

push した直後に、メッセージを amend します。

git commit --amend -m "todoとdraftを追加した"
git status -sb

[main c84eb08] todoとdraftを追加した
 Date: Sat Oct 3 04:21:49 2026 +0900
 3 files changed, 3 insertions(+)
 create mode 100644 draft.txt
 create mode 100644 todo.txt

## main...origin/main [ahead 1, behind 1]
?? secret.env

[ahead 1, behind 1] に注目してください。手元が1コミット進み、同時に1コミット遅れているという表示です。この状態で push すると、次のようになります。

git push

To ../remote.git
 ! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to '../remote.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. If you want to integrate the remote changes,
hint: use 'git pull' before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

なぜ「遅れている」と言われるのか

理由は、amend がコミットを差し替える操作だからです。

flowchart LR
    R[61eb25a 最初のコミット] --> O[c8c27e2 リモートにある元のコミット]
    R --> N[c84eb08 amendで作った新しいコミット]

リモートの先端は c8c27e2、手元の先端は c84eb08 で、どちらも 61eb25a から枝分かれした別のコミットです。Git の push は、リモートの先端の続きにコミットを足す形（fast-forward）だけを通常は受け付けます。 手元の履歴にリモートの c8c27e2 が含まれていないため、「リモートにあるコミットをまだ取り込んでいない」と判断されて止まります。

対処の選び方

自分専用のブランチで実行した結果です。

git push --force-with-lease

To ../remote.git
 + c8c27e2...c84eb08 main -> main (forced update)

+ と (forced update) が、履歴を置き換えたことを示しています。--force-with-lease は「リモートが、自分が最後に確認した状態のままなら置き換える」という条件付きの強制 push です。ほかの人が先に push していた場合は止まってくれるので、--force よりも落ち着いて使えます。

ここで git pull を選ぶと、元のコミットと amend 後のコミットが両方残り、マージコミットも増えます。 ヒントには pull が案内されますが、amend が原因の rejected では「置き換える」か「amend をやめる」かのどちらかを選ぶと履歴がすっきりします。

add のオプション（-A・.・-u・-p）の対象範囲

git add の後ろに何を書くかで、ステージに載る範囲が変わります。次の状態を作って、それぞれ実行した結果を比べました。

# 準備：mod.txt / del.txt / sub/mod2.txt をコミット済みにしてから
echo M >> mod.txt        # 変更（ルート）
rm del.txt               # 削除（ルート）
echo n > new.txt         # 新規（ルート）
echo M >> sub/mod2.txt   # 変更（sub フォルダ）
echo n > sub/new2.txt    # 新規（sub フォルダ）

git status --short は、1文字目がステージの状態、2文字目が作業ツリーの状態です。左に寄っている文字は「add 済み」、右に寄っている文字と ?? は「まだ add していない」と読みます。

git add -A（ルートで実行）:

D  del.txt
M  mod.txt
A  new.txt
M  sub/mod2.txt
A  sub/new2.txt

git add .（ルートで実行）:

D  del.txt
M  mod.txt
A  new.txt
M  sub/mod2.txt
A  sub/new2.txt

git add -u（ルートで実行）:

D  del.txt
M  mod.txt
M  sub/mod2.txt
?? new.txt
?? sub/new2.txt

git add .（sub フォルダに移動して実行）:

 D del.txt
 M mod.txt
M  sub/mod2.txt
A  sub/new2.txt
?? new.txt

対象範囲の比較表

リポジトリのルートで実行するなら、git add -A と git add . は同じ結果になります。 違いが出るのはサブフォルダで実行したときで、. は「今いる場所から下」だけを対象にします。Git 2.x の公式ドキュメント（git-add、今回 2.56.0 版のページで確認）にも、. のようにフォルダを指定した場合は削除されたファイルも記録されること、-A と -u はパスを省略すると作業ツリー全体が対象になることが書かれています。Git 1.x の時代は git add . が削除を拾わなかったため、その頃の説明と食い違って見えることがあります。

変更の一部だけを選ぶ（git add -p）

1つのファイルに2か所の変更があり、片方だけを先にコミットしたい場面で使います。12行のファイル p.txt の1行目と12行目を書き換えてから実行しました。

git add -p

diff --git a/p.txt b/p.txt
index 2f0b8ee..7c0e76b 100644
--- a/p.txt
+++ b/p.txt
@@ -1,4 +1,4 @@
-a
+A
 b
 c
 d
(1/2) Stage this hunk [y,n,q,a,d,j,J,g,/,e,?]? y
@@ -9,4 +9,4 @@ h
 i
 j
 k
-l
+L
(2/2) Stage this hunk [y,n,q,a,d,K,g,/,e,?]? n

1つ目に y（載せる）、2つ目に n（載せない）と答えた後の状態です。

git status --short
git diff --cached --stat

MM p.txt

 p.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

MM は「ステージに載った変更と、まだ載っていない変更の両方がある」状態です。よく使う応答キーをまとめます。

add で出会うメッセージと対処

上の2つは実際に出力を確認しました。.gitignore 対象のファイルを add したときの全文は次のとおりです。

The following paths are ignored by one of your .gitignore files:
x.log
hint: Use -f if you really want to add them.
hint: Turn this message off by running
hint: "git config advice.addIgnoredFile false"

commit -am は新規ファイルを含まない

git commit -am は「git add -u してから commit」と同じ範囲で動きます。p.txt の変更と、新しく作った .gitignore がある状態で実行した結果です。

git commit -am "追跡済みだけまとめて"
git status --short

[main 16de378] 追跡済みだけまとめて
 1 file changed, 2 insertions(+), 2 deletions(-)

?? .gitignore

新規ファイルの .gitignore は未追跡のまま残りました。 新しいファイルを作ったときは、git add を明示的に打つ必要があります。

状況別：やり直しの早見表

「いまどの段階にいるか」から、使うコマンドを選べる表です。

共通の考え方は「push 前なら書き換えてよい、push 後の共有ブランチでは足す方向で直す」です。 push 前のコミットは自分の手元にしかないので、amend で整えてから共有すると、読みやすい履歴になります。

作業前後のチェックリスト

パスワードや API キーを書いたファイルは、add する前に .gitignore へ追加しておくと、git add -A を使っても載らなくなります。

よくある質問

Q. git add を取り消すと、編集した内容も消えますか？ A. 消えません。git restore --staged <ファイル>、git reset HEAD <ファイル>、git rm --cached <ファイル> はどれもステージから外すだけで、ファイルの中身はそのまま残ります。編集内容が元に戻るのは --staged を付けない git restore <ファイル> のほうなので、オプションの有無を確認してから実行してください。

Q. git add -A と git add . はどちらを使えばよいですか？ A. リポジトリのルートで実行するなら結果は同じです。サブフォルダにいるときに「リポジトリ全体」を載せたいなら -A、「今いるフォルダ以下だけ」を載せたいなら . を選びます。どちらの場合も、実行後に git status で載った範囲を確認すると確実です。

Q. git commit --amend でコミット ID が変わるのはなぜですか？ A. コミット ID は、内容・メッセージ・親コミット・日時などから計算される値だからです。メッセージを1文字変えるだけでも別の値になります。amend は元のコミットを編集するのではなく、新しいコミットを作って差し替える操作だと考えると理解しやすくなります。

Q. 2つ前のコミットのメッセージを直したいときは？ A. --amend が扱えるのは直前の1つだけです。2つ以上前のコミットは git rebase -i HEAD~2 のように対話的リベースを使い、対象の行を reword に変えて直します。push 済みの共有ブランチでは、履歴の書き換えを避けてそのままにしておく選択も一般的です。

まとめ

• git add は次のコミットに入れる変更を選ぶ、git commit は選んだ変更を記録する。前後に git status を打つと現在地がわかる
• add の取り消しは git restore --staged <ファイル>。初回コミット前は fatal: could not resolve HEAD になるので git rm --cached <ファイル> を使う
• git restore は --staged の有無で意味が変わる。付けないと作業ツリーの編集内容が元に戻る
• メッセージだけ直すなら git commit --amend -m "..."、ファイルを足すなら add してから git commit --amend --no-edit
• amend するとコミット ID が変わる。push 済みのコミットを amend すると [ahead 1, behind 1] になり、push が non-fast-forward で rejected になる
• 自分専用ブランチなら git push --force-with-lease、共有ブランチなら修正を新しいコミットとして足す
• git add -A は全体、. は今いるフォルダ以下、-u は追跡済みのみ、-p は変更の一部だけを載せる

株式会社RJCでは、git add・commitをはじめとするGitの基本操作を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。