1326

gitがgit rm --cachedファイルのステージングを解除することを提案する場合もあれば、git reset HEAD file。いつどちらを使うべきですか？

編集：

D:\code\gt2>git init
Initialized empty Git repository in D:/code/gt2/.git/
D:\code\gt2>touch a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       a
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add a

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a
#
D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
 0 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 a

D:\code\gt2>touch b

D:\code\gt2>git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       b
nothing added to commit but untracked files present (use "git add" to track)

D:\code\gt2>git add b

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#
4

14 に答える 14

2120

git rm --cached <filePath> ファイルのステージングを解除するのではなく、実際にリポジトリからのファイルの削除をステージングします（以前にコミットされていると仮定します）が、ファイルは作業ツリーに残されます（追跡されていないファイルが残ります）。

git reset -- <filePath>指定されたファイルのステージングされた変更をアンステージングします。

とはいえ、ステージングされた新しいファイルを使用git rm --cachedした場合、それは以前にコミットされたことがないため、基本的にはステージングを解除したように見えます。

git 2.24を更新します。この新しいバージョンのgitでは、の代わりに
使用できます。gitdocsを参照してください。git restore --stagedgit reset

于 2011-08-02T22:03:13.717 に答える
346

git rm --cachedインデックスからファイルを削除するために使用されます。ファイルがすでにリポジトリにある場合は、ファイルgit rm --cachedをインデックスから削除し、作業ディレクトリに残します。コミットすると、ファイルもリポジトリから削除されます。基本的に、コミット後、ファイルのバージョンを解除し、ローカルコピーを保持します。

git reset HEAD file（デフォルトでは--mixedフラグを使用している）ファイルがすでにリポジトリにある場合は、ファイルのインデックスバージョンをリポジトリ（HEAD）のものに置き換え、ファイルへの変更を効果的にアンステージするという点で異なります。

バージョン管理されていないファイルの場合、ファイルがHEADになかったため、ファイル全体のステージングが解除されます。この点git reset HEAD fileでgit rm --cachedは、同じですが、同じではありません（すでにリポジトリにあるファイルの場合に説明されているように）

質問に対してWhy are there 2 ways to unstage a file in git?-gitで何かをする方法は本当に1つだけではありません。それはそれの美しさです:)

于 2011-08-02T23:00:25.413 に答える
139

非常に単純に：

  • git rm --cached <file> gitがファイルの追跡を完全に停止しますgit rm（プレーン*とは異なり、ファイルシステムに残します）
  • git reset HEAD <file> 最後のコミット以降にファイルに加えられた変更をステージング解除します（ただし、コマンド名が示唆するものとは異なり、ファイルシステムでそれらを元に戻すことはありません**）。ファイルはリビジョン管理下にあります。

ファイルが以前にリビジョン管理されていなかった場合（つまりgit add、初めて編集したファイルのステージングを解除している場合）、2つのコマンドの効果は同じであるため、これらの外観は「何かを行う2つの方法」になります。 "。

*以前にリポジトリにコミットgit rm --cachedされたファイルに関して、@DrewTが回答で言及している警告に注意してください。この質問のコンテキストでは、追加されたばかりでまだコミットされていないファイルについては、心配する必要はありません。

** git resetコマンドを使用するのは、その名前のせいで恥ずかしいほど長い間怖かったです。それでも今日でも、構文を調べて、失敗しないようにしています。（更新：私はついにtldrページでの使用法を要約するgit resetのに時間をかけたので、それがどのように機能するかについてのより良いメンタルモデルと、詳細を忘れたときのクイックリファレンスができました。）

于 2014-10-17T21:16:01.983 に答える
58

このスレッドは少し古いですが、それでも直感的な問題ではないため、少しデモンストレーションを追加したいと思います。

me$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   new file:   to-be-added
#   modified:   to-be-modified
#   deleted:    to-be-removed
#

me$ git reset -q HEAD to-be-added

    # ok

me$ git reset -q HEAD to-be-modified

    # ok

me$ git reset -q HEAD to-be-removed

    # ok

# or alternatively:

me$ git reset -q HEAD to-be-added to-be-removed to-be-modified

    # ok

me$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   modified:   to-be-modified
#   deleted:    to-be-removed
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   to-be-added
no changes added to commit (use "git add" and/or "git commit -a")

git reset HEAD（なし-q）は、変更されたファイルに関する警告を表示し、その終了コードは1であり、スクリプトのエラーと見なされます。

編集：git checkout HEAD to-be-modified to-be-removedステージング解除にも機能しますが、ワークスペースから変更を完全に削除します

git 2.23.0の更新：コマンドは時々変更されます。今、git status言います：

  (use "git restore --staged <file>..." to unstage)

...これは3つのタイプの変更すべてに対応します

于 2013-04-16T19:00:37.823 に答える
37

コミットしたくないファイルを誤ってステージングし、変更を確実に保持したい場合は、次を使用することもできます。

git stash
git stash pop

これにより、HEADへのリセットが実行され、変更が再適用され、コミットのために個々のファイルを再ステージングできるようになります。これは、プルリクエスト用の機能ブランチを作成するのを忘れた場合にも役立ちます（git stash ; git checkout -b <feature> ; git stash pop）。

于 2015-02-10T17:06:19.053 に答える
16

問題のファイルがすでにリポジトリにあり、バージョン管理下にある場合（以前にコミットされた場合など）、これら2つのコマンドにはいくつかの微妙な違いがあります。

  • git reset HEAD <file>現在のコミットでファイルのステージングを解除します。
  • git rm --cached <file>将来のコミットのためにもファイルのステージングを解除します。で再度追加されるまで、ステージングされませんgit add <file>。

そして、もう1つの重要な違いがあります。

  • ブランチを実行git rm --cached <file>してリモートにプッシュした後、リモートからブランチをプルすると、ローカルのワーキングセットでファイルが追跡されなくなった（つまり、フォルダーから物理的に削除されなかった）場合でも、ファイルはフォルダーから実際に削除されます。

この最後の違いは、チームの各開発者が異なる構成（つまり、異なるベースURL、IP、またはポート設定）を持つ構成ファイルを含むプロジェクトにとって重要であるためgit rm --cached <file>、ブランチをプルする人を使用している場合は、手動で再作成する必要があります。設定を作成するか、設定を送信して、IP設定（など）に再編集することができます。削除は、リモートからブランチをプルするユーザーにのみ影響するためです。

于 2014-08-10T20:04:38.933 に答える
11

stageを介してディレクトリ全体をgit add <folder>作成するとしますが、ステージングされたリスト（実行時に生成されるリストgit status）からファイルを除外し、除外されたファイル内で変更を保持したいとします（何かに取り組んでいて、コミットの準備ができていませんが、あなたはあなたの仕事を失いたくない...）。あなたは単に使うことができます：

git reset <file>

を実行するgit statusと、自分がどのファイルであってもreset、unstaged残りのファイルがリストaddedに残っていることがわかりますstaged。

于 2015-08-28T16:08:05.590 に答える
11

1.1。

D:\code\gt2>git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   a

（ステージングを解除するには、「git rm --cached ...」を使用します）

  • gitはポインタのシステムです

  • ポインタをに変更するコミットはまだありません

  • 'ポイントされているバケットからファイルを取り出す'唯一の方法は、変更を監視するようにgitに指示したファイルを削除することです。

2.2。

D:\code\gt2>git commit -m a
[master (root-commit) c271e05] a
0 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 a

git commit -ma

  • あなたがコミットした、'保存された'

3.3。

D:\code\gt2>git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   b
#

（「gitreset HEAD ...」を使用してステージングを解除します）

  • この時点でコードをコミットしました
  • これで、コミットへのポインタをリセットできます'最後の保存に戻ります'
于 2016-09-08T16:26:07.657 に答える
8

2.2を超える新しいバージョンでは、を使用できますgit restore --staged <file_name>。ここで注意してくださいファイルを一度に1つずつステージング解除（変更に移動）する場合は、ファイル名を指定して上記のコマンドを使用します。例えば

git restore --staged abc.html

これで、すべてのファイルを一度にアンステージしたい場合は、次のようにすることができます

git restore --staged .

スペースとドット（。）は、すべてのファイルをステージングすることを意味することに注意してください。

于 2021-02-12T12:53:06.350 に答える
6

使用するだけです：

git reset HEAD <filename>

これにより、ファイルのステージングが解除され、ファイルに加えた変更が保持されるため、必要に応じてブランチを変更し、git add代わりにそれらのファイルを別のブランチに変更できます。すべての変更が保持されます。

于 2019-09-10T23:38:59.310 に答える
5

誰もgitreflog（http://git-scm.com/docs/git-reflog）について言及していないことに驚いています。

# git reflog
<find the place before your staged anything>
# git reset HEAD@{1}

reflogは、リポジトリへの変更を追跡するだけでなく、ユーザーアクション（プル、別のブランチへのチェックアウトなど）も追跡し、それらのアクションを元に戻すことができるgit履歴です。したがって、誤ってステージングされたファイルのステージングを解除する代わりに、ファイルをステージングしなかったポイントに戻すことができます。

これは似てgit reset HEAD <file>いますが、場合によってはよりきめ細かくなります。

申し訳ありませんが、実際にはあなたの質問に答えていませんが、私が頻繁に使用するファイルのステージングを解除するためのさらに別の方法を示しています（Ryan Stewartによる回答が好きで、非常にワルディリアスです）;）お役に立てば幸いです。

于 2015-02-10T12:06:40.783 に答える
5

バージョン2.23以降の場合のみ、

これらの提案の代わりに、ファイルを作成git restore --staged <file>するために使用できます 。unstage

于 2019-10-29T15:20:35.673 に答える
4

OSがバージョン管理を削除せずにディレクトリからファイルを削除するのと 同じようgit rm --cached <file>に、プレーンが両方を実行するディレクトリからファイルを削除せずに、インデックスからファイルを削除するように思えます。git rm <file>rm <file>

于 2013-06-06T12:06:01.867 に答える
0

ファイルのステージングを解除する（git addを元に戻す）

git restore --staged file.js ＃file.jsの最後のバージョンをリポジトリからインデックスにコピーします

ローカル変更の破棄

git restore file.js ＃file.jsをインデックスから作業ディレクトリにコピーします

git restore file1.js file2.js ＃作業ディレクトリ内の複数のファイルを復元します

gitrestore。＃すべてのローカル変更を破棄します（追跡されていないファイルを除く）

git clean -fd ＃追跡されていないすべてのファイルを削除します

于 2022-01-17T08:23:59.340 に答える