git rmの使い方｜–cachedで管理対象から外す方法とgit mv

git rm とは、ファイルを「作業ツリー（手元のフォルダ）」と「インデックス（次のコミットに入れる内容の一覧）」の両方から削除するコマンドです。 --cached を付けると、手元のファイルは残したままインデックスからだけ外れ、Gitの管理対象でなくなります。名前の変更や移動には git mv を使います。

この記事では、rm・git rm・git rm --cached・git mv の4つを同じリポジトリで実行し、git status の出力全文を並べて違いを確かめます。.gitignore に書いたのに追跡が続くファイルの外し方、「local modifications」エラーの再現、git restore での取り消し、push後にほかのメンバーの手元で起きること、リネーム検出の挙動まで、すべて Git 2.43.0 で実際に実行した結果を載せています。出力中のユーザー名とパスは、taro、/home/taro のような一般的な名前に置き換えています。

git rm・git mv の早見表

どのコマンドも、実行しただけでは履歴（コミット）は変わりません。 git commit をして初めて「削除した」「名前を変えた」という記録が履歴に入ります。また、過去のコミットに入っているファイルの内容は、git rm をしても履歴の中に残ります。

先に押さえる3つの場所：作業ツリー・インデックス・履歴

git rm の動きは、Gitがファイルを置いている3つの場所で考えるとすっきりします。

「Gitの管理対象（追跡されている）」とは、インデックスに載っている状態のことです。git rm --cached が「管理対象から外す」コマンドになるのは、インデックスからだけ取り除くからです。

4つのコマンドの対比表

a.txt と b.txt がコミット済みの状態から、それぞれのコマンドを実行した直後（コミット前）の状態です。

flowchart LR
  subgraph S1["rm a.txt"]
    A1["作業ツリー: 消える"] --- A2["インデックス: 残る"]
  end
  subgraph S2["git rm a.txt"]
    B1["作業ツリー: 消える"] --- B2["インデックス: 消える"]
  end
  subgraph S3["git rm --cached a.txt"]
    C1["作業ツリー: 残る"] --- C2["インデックス: 消える"]
  end

4つのコマンドを実行して git status を見比べる

検証用のリポジトリは次のコマンドで作りました。そのまま貼って試せます。

git init work && cd work
printf 'line1\nline2\nline3\n' > a.txt
echo b > b.txt; echo c > c.txt; echo d > d.txt
git add -A && git commit -m "initial"

rm（OSのコマンド）で消した場合

rm a.txt
git status

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

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

作業ツリーからは消えましたが、インデックスにはまだ a.txt が載っています。そのため「Changes not staged for commit（ステージされていない変更）」に deleted と出ます。このあと git rm a.txt か git add a.txt を実行すると削除がステージされ、次の git rm と同じ状態になります。元に戻すなら git restore a.txt です。

git rm で消した場合

git rm a.txt
git status

rm 'a.txt'

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    a.txt

「rm 'a.txt'」は git rm が出すメッセージです。作業ツリーからもインデックスからも消え、削除がステージされた状態になります。あとは git commit するだけです。rm と git add の2手順を1回で済ませるコマンド、と考えるとわかりやすくなります。

git rm --cached で管理対象から外した場合

git rm --cached a.txt
git status

rm 'a.txt'

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    a.txt

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

メッセージは同じ「rm 'a.txt'」ですが、ls で確かめるとファイルは手元に残っています。

$ ls
a.txt
b.txt
c.txt
d.txt

同じ a.txt が「deleted（削除をステージ済み）」と「Untracked files（未追跡）」の両方に出るのが、--cached の目印です。 インデックスからは消えた（＝次のコミットで削除として記録される）一方、作業ツリーには残っているので、Gitから見ると「知らないファイルが置いてある」状態になります。

git mv で名前を変えた場合

git mv b.txt b2.txt
git status

On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    renamed:    b.txt -> b2.txt

作業ツリーの名前が変わり、インデックスにもリネームとしてステージされます。git mv は成功時にメッセージを出しません。

git rm の基本の使い方とオプション

git rm [オプション] <ファイルやフォルダ>...

フォルダを削除する（-r）と、先に確かめる（-n）

logs フォルダに x.log、y.log、keep.txt がコミット済みの状態で試します。-r を付けずにフォルダを指定すると止まります。

$ git rm logs
fatal: not removing 'logs' recursively without -r

-n を付けると、削除されるファイルの一覧だけを表示できます。 フォルダやパターンを指定するときは、先にこれで確かめると安心です。

$ git rm -n -r logs
rm 'logs/keep.txt'
rm 'logs/x.log'
rm 'logs/y.log'

-n を外して実行すると、同じ3行が表示されて実際に削除され、空になった logs フォルダも作業ツリーから消えました。

パターンで指定する

$ git rm 'logs/*.log'
rm 'logs/x.log'
rm 'logs/y.log'

$ git status --short
D  logs/x.log
D  logs/y.log

パターンをシングルクォートで囲むと、シェルではなくGitがパターンを解釈し、追跡中のファイルだけが対象になります。

追跡されていないファイルには使えない

$ git rm untracked.txt
fatal: pathspec 'untracked.txt' did not match any files

git rm が扱えるのは、インデックスに載っているファイルだけです。一度も git add していないファイルは、OSの rm で削除します。

.gitignoreに書いたのに追跡が続くファイルを --cached で外す

「.gitignore に書いたのに、変更が git status に出続ける」というのは、とてもよくある場面です。.gitignore が効くのは、まだ追跡されていないファイルだけで、すでにコミット済みのファイルには効きません。git rm --cached でインデックスから外すと、.gitignore が効くようになります。

debug.log と config.local をうっかりコミットしてしまったリポジトリで、流れを通して実行します。

1. .gitignore に書いても、変更が表示される

echo "debug.log" > .gitignore
echo "config.local" >> .gitignore
git add .gitignore && git commit -m "add .gitignore"
echo "more" >> debug.log
git status --short

 M debug.log

.gitignore に書いたあとも、debug.log の変更が「M」と表示されました。git ls-files（追跡中のファイル一覧）で見ると、2つとも載ったままです。

$ git ls-files
.gitignore
README.md
app.py
config.local
debug.log

このとき git check-ignore -v debug.log を実行しても、何も表示されませんでした。追跡中のファイルは「無視されている」と判定されないためです。

2. git rm --cached でインデックスから外す

$ git rm --cached debug.log config.local
rm 'config.local'
rm 'debug.log'

$ git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    deleted:    config.local
    deleted:    debug.log

先ほどの a.txt の例と違い、Untracked files が表示されていません。 .gitignore に書かれているので、未追跡になったファイルが一覧から省かれるためです。

3. コミットして、効いていることを確かめる

$ git commit -m "Stop tracking debug.log and config.local"
[main 835d53c] Stop tracking debug.log and config.local
 2 files changed, 2 deletions(-)
 delete mode 100644 config.local
 delete mode 100644 debug.log

もう一度 debug.log に追記してから確かめます。

$ echo "more2" >> debug.log
$ git status --short
（何も表示されない）

$ ls -A
.git
.gitignore
README.md
app.py
config.local
debug.log

$ git ls-files
.gitignore
README.md
app.py

$ git check-ignore -v debug.log
.gitignore:1:debug.log  debug.log

ファイルは手元に残ったまま、git ls-files から消え、変更しても git status に出なくなりました。check-ignore も「.gitignore の1行目のルールで無視されている」と答えるようになっています。

.gitignore と git rm --cached の順番はどちらが先でもかまいませんが、同じコミットか続けてのコミットに入れておくと、再び git add -A で追加されることがありません。

なお、この操作で外れるのは「これから先」の追跡だけです。過去のコミットにはファイルの内容が残っています。パスワードやAPIキーなどを含むファイルだった場合は、キーの無効化と再発行を先に行い、履歴からの削除は別の手順として検討します。

push後、ほかのメンバーの手元ではファイルが消える

git rm --cached は「自分の手元には残す」コマンドですが、そのコミットを受け取ったほかのメンバーの手元では、ファイルが作業ツリーから削除されます。 Gitの履歴の上では「ファイルを削除したコミット」だからです。

上の「Stop tracking ...」のコミットを push し、別のメンバー（hanako）のクローンで pull した結果です。

$ ls -A
.git
README.md
app.py
config.local
debug.log

$ git pull
From /home/taro/g/remote
   830b694..835d53c  main       -> origin/main
Updating 830b694..835d53c
Fast-forward
 .gitignore   | 2 ++
 config.local | 1 -
 debug.log    | 1 -
 3 files changed, 2 insertions(+), 2 deletions(-)
 create mode 100644 .gitignore
 delete mode 100644 config.local
 delete mode 100644 debug.log

$ ls -A
.git
.gitignore
README.md
app.py

pull の前にあった config.local と debug.log が、pull のあとには手元から消えています。

相手がそのファイルを編集していた場合は、pullが止まる

別のクローンで config.local を編集してから pull すると、次のように止まりました。

$ git pull
From /home/taro/g/remote
   830b694..835d53c  main       -> origin/main
error: Your local changes to the following files would be overwritten by merge:
    config.local
Please commit your changes or stash them before you merge.
Aborting
Updating 830b694..835d53c

$ git status --short
 M config.local

Gitが未コミットの変更を守って、取り込みを中断しています。この時点ではファイルは手元に残っています。

メンバーへの伝え方

各自の設定ファイルを管理対象から外すときは、次のように伝えておくとスムーズです。

ひな形として config.local.example のようなファイルをリポジトリに置き、各自がコピーして使う形にしておくと、新しく参加した人も同じ手順で準備できます。

「local modifications」エラーの再現と -f の意味

git rm には、まだコミットしていない変更が消えないように守る確認が入っています。変更の状態ごとに、表示されるエラーが違います。

作業ツリーに未ステージの変更がある場合

$ echo edit >> c.txt
$ git rm c.txt
error: the following file has local modifications:
    c.txt
(use --cached to keep the file, or -f to force removal)

変更をステージ済みの場合

$ git add c.txt
$ git rm c.txt
error: the following file has changes staged in the index:
    c.txt
(use --cached to keep the file, or -f to force removal)

ステージ済みの変更に加えて、さらに編集した場合

$ echo edit2 >> c.txt
$ git rm c.txt
error: the following file has staged content different from both the
file and the HEAD:
    c.txt
(use -f to force removal)

この状態では git rm --cached c.txt も同じエラーで止まりました。インデックスにしかない内容（1回目の編集をステージしたもの）が、どこにも残らなくなるためです。

エラーと対応の一覧

未ステージの変更がある d.txt に --cached を使った結果です。エラーにならず、変更後のファイルが未追跡として残りました。

$ echo edit >> d.txt
$ git rm --cached d.txt
rm 'd.txt'

$ git status --short
D  d.txt
?? d.txt

-f は「変更ごと削除してよい」という意思表示

$ git rm -f c.txt
rm 'c.txt'

$ git status --short
D  c.txt

-f を付けると確認を飛ばして削除します。コミットしていなかった変更は一緒に消え、git restore で戻るのは最新のコミットの内容までです。 エラーが出たら、まず次の3つから選ぶのがおすすめです。

git rm を取り消す（git restore の状態別早見表）

取り消し方は、「コミット前か後か」「どのコマンドで消したか」で決まります。

git rm の取り消しを2段階で見る

$ git rm a.txt
rm 'a.txt'

$ git restore --staged a.txt
$ git status --short
 D a.txt

$ git restore a.txt
$ git status --short
（何も表示されない）

git restore --staged でインデックスが戻り、表示が「削除をステージ済み」から「未ステージの削除（左が空白、右がD）」に変わります。続けて git restore a.txt で作業ツリーにファイルが戻ります。この2つを1回で行うのが --staged --worktree の指定です。

$ git restore --staged --worktree a.txt
$ git status --short
（何も表示されない）
$ ls
a.txt
b.txt
c.txt
d.txt

git rm --cached の取り消し

$ git restore --staged a.txt
$ git status --short
（何も表示されない）

ファイルは手元にあるので、インデックスを戻すだけで元どおりです。

コミット後に取り消す

削除をコミットしたあとで、そのコミットを打ち消した結果です。

$ git revert --no-edit HEAD
[main 6360fe9] Revert "Remove run.py"
 Date: Sat Oct 3 11:33:49 2026 +0900
 1 file changed, 7 insertions(+)
 create mode 100644 run.py

revert は「削除を取り消す新しいコミット」を足すので、push済みのブランチでもそのまま使えます。削除コミットに含まれるほかの変更は残して、1ファイルだけ戻したいときは git restore --source=HEAD~1 --staged --worktree run.py を使います。実行後の git status --short は「A run.py」（追加としてステージ済み）でした。

git mv の使い方と、手動 mv との違い

git mv <元の名前> <新しい名前>      # 名前を変える
git mv <ファイル> <フォルダ>/       # フォルダへ移動する

フォルダへの移動も同じコマンドです。

$ git mv a.txt logs/
$ git status --short
R  a.txt -> logs/a.txt

手動で mv した場合の git status

OSの mv で名前を変えると、最初は「削除」と「未追跡のファイル」に分かれて表示されます。

$ mv b.txt b2.txt
$ git status
On branch main
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    b.txt

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

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

ここで git add -A を実行すると、git mv と同じ表示になりました。

$ git add -A
$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    renamed:    b.txt -> b2.txt

Gitは「リネームした」という情報そのものを記録していません。 コミットに入るのは「b.txt がなくなり、b2.txt が増えた」というスナップショットで、表示のたびに内容の似かたを比べてリネームと判定しています。そのため、git mv でも「mv のあとに git add -A」でも、記録される結果は同じです。git mv は「mv、元の名前の git rm、新しい名前の git add」を1回で済ませる近道といえます。

リネーム検出は「内容の似かた」で決まる

コミット時の表示で、リネーム検出の様子を確かめます。

名前だけ変えた場合（git mv）です。

$ git mv app.py main.py
$ git commit -m "Rename app.py to main.py"
[main c9ac5d0] Rename app.py to main.py
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename app.py => main.py (100%)

手動 mv と git add -A でも、同じく100%のリネームと表示されました。

$ git commit -m "Rename README by hand"
[main 2f2a152] Rename README by hand
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename README.md => GUIDE.md (100%)

名前を変えて、1行だけ追記した場合です（5行のファイルに1行追加）。

$ git commit -m "Rename and small edit"
[main 6a09332] Rename and small edit
 1 file changed, 1 insertion(+)
 rename GUIDE.md => MANUAL.md (80%)

かっこの中の数字が、内容の似かた（類似度）です。80%でもリネームと判定されました。

名前を変えて、中身をほぼすべて書き換えた場合です。

$ git status --short
D  main.py
A  run.py

$ git commit -m "Rename and rewrite"
[main 4a03e09] Rename and rewrite
 2 files changed, 7 insertions(+), 6 deletions(-)
 delete mode 100644 main.py
 create mode 100644 run.py

こちらはリネームではなく「削除」と「新規作成」として表示されました。

同じコミットを、検出の有無を切り替えて表示した結果です。

$ git diff -M --name-status HEAD~1 HEAD
R080    GUIDE.md    MANUAL.md

$ git diff --no-renames --name-status HEAD~1 HEAD
D   GUIDE.md
A   MANUAL.md

記録されている内容は同じで、見せ方だけが変わっていることがわかります。

履歴をたどりやすくするコツ

名前を変える前の履歴を見るには、git log に --follow を付けます。

$ git log --oneline --follow -- main.py
c9ac5d0 Rename app.py to main.py
830b694 initial

$ git log --oneline -- main.py
c9ac5d0 Rename app.py to main.py

--follow を付けると、app.py だったころのコミット（initial）までさかのぼれました。一方、全面書き換えと同時に名前を変えた run.py では、--follow を付けても1件だけでした。

$ git log --oneline --follow -- run.py
4a03e09 Rename and rewrite

「名前の変更」と「中身の変更」を別々のコミットに分けると、リネームとして検出されやすくなり、あとから履歴をたどりやすくなります。

git mv が止まる例

$ git mv untracked.txt u2.txt
fatal: not under version control, source=untracked.txt, destination=u2.txt

$ git mv a.txt b.txt
fatal: destination exists, source=a.txt, destination=b.txt

大文字・小文字だけの変更も git mv で行えます。

$ git mv MANUAL.md manual.md
$ git status --short
R  MANUAL.md -> manual.md

この結果はLinuxで確かめたものです。WindowsやmacOSの標準設定のように大文字・小文字を区別しないファイルシステムでの動作は、今回は未実行です。

目的別：どのコマンドを使うかの判断表

よくある質問

Q. git rm と rm の違いは何ですか？ A. rm はOSのコマンドで、作業ツリーのファイルを消すだけです。削除をコミットに入れるには、あとで git add か git rm が必要です。git rm は、作業ツリーからの削除と、削除のステージを1回で行います。

Q. git rm --cached をすると、ファイルは消えますか？ A. 自分の手元のファイルは消えません。インデックスから外れるだけです。ただし、そのコミットを pull したほかのメンバーの手元では、作業ツリーからファイルが削除されます。各自で必要なファイルの場合は、push の前に一言伝えておくと安心です。

Q. git rm したファイルは、履歴からも消えますか？ A. 消えません。git rm が記録するのは「このコミット以降はファイルがない」という変化で、それより前のコミットには内容が残っています。git restore --source=<コミット> ファイル で取り出せます。

Q. 「error: the following file has local modifications」と出ました。どうすればよいですか？ A. まだコミットしていない変更があるため、Gitが削除を止めています。変更を残したいなら git rm --cached を使うか、先にコミットしてから git rm します。変更が不要なら git rm -f で削除できます。

まとめ

• git rm は作業ツリーとインデックスの両方から削除し、削除をステージする。履歴に入るのは commit したとき
• git rm --cached はインデックスからだけ削除。手元のファイルは残り、git status には deleted と Untracked files の両方が出る
• .gitignore はコミット済みのファイルには効かない。git rm --cached で外してコミットすると効くようになる
• push後、ほかのメンバーが pull するとそのファイルは手元から消える。編集中だった場合は pull が止まる
• local modifications などのエラーは、未コミットの変更を守るための確認。-f は変更ごと削除する指定
• 取り消しは、コミット前なら git restore（--staged / --worktree）、コミット後なら git revert
• git mv と「mv のあとに git add -A」は同じ結果。リネームは内容の似かたで検出されるので、名前の変更と中身の変更はコミットを分ける

株式会社RJCでは、git rmやgit mvといったGitの使い方を仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

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