コミットする前に「git add」を元に戻すにはどうすればよいですか？

次のコマンドを使用して、誤ってGitにファイルを追加しました。

git add myfile.txt

まだ走っていませんgit commit。これを元に戻す方法はあるので、これらのファイルはコミットに含まれませんか？

git addコミットする前に元に戻すことができます

git reset <file>

何も変更せずに現在のインデックス（「コミットされる」リスト）から削除されます。

使用できます

git reset

すべての変更をステージング解除するためのファイル名なし。これは、妥当な時間内に1つずつリストするにはファイルが多すぎる場合に便利です。

Gitの古いバージョンでは、上記のコマンドはgit reset HEAD <file>およびと同等です。git reset HEADそれぞれ、HEADが未定義の場合（リポジトリでまだコミットを行っていないため）、またはあいまいな場合（というブランチを作成したためHEAD、愚かなことです）あなたがすべきではないこと）。ただし、これはGit 1.8.2で変更されたため、最新バージョンのGitでは、最初のコミットを行う前でも上記のコマンドを使用できます。

「git reset」（オプションまたはパラメーターなし）は、履歴にコミットがない場合にエラーを出力するために使用されていましたが、空のインデックスを提供します（存在しないコミットと一致させるために、あなたも偶然ではありません）。

あなたが欲しい：

git rm --cached <added_file_to_undo>

推論：

私はこれが初めてだったとき、私は最初に試しました

git reset .

（私の最初の追加全体を元に戻すため）、これだけではない（そうではない）有用なメッセージを取得する：

fatal: Failed to resolve 'HEAD' as a valid ref.

これは、最初のコミットが完了するまでHEAD ref（branch？）が存在しないためです。つまり、私のようなワークフローが次のようなものだった場合、私と同じ初心者の問題が発生します。

1. 新しいプロジェクトディレクトリにcdして、新しいホットなGitを試す
2. git init
3. git add .

4. git status

   ...がらくたがたくさんスクロール...

   =>くそー、私はそれをすべて追加したくありませんでした。

5. google「元に戻すgit追加」

   =>スタックオーバーフローを検索-はい

6. git reset .

   =>致命的： 'HEAD'を有効な参照として解決できませんでした。

さらに、ログに記録されたバグがあることがわかりました、これの役に立たないことに対してメーリングリストにわかりました。

そして、正しい解決策がGitステータス出力にあることを確認しました（はい、私は「がらくた」と書き直しました）

...
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
...

そして解決策は実際に使用することです git rm --cached FILEです。

ここの他の場所の警告に注意してください- git rmローカルのファイルの作業コピーを削除しますが、-- cachedを使用する場合は削除しません。これが結果です：git help rm

--cachedこのオプションを使用して、ステージングを解除し、インデックスからのみパスを削除します。変更されたかどうかに関係なく、作業ツリーファイルは残されます。

使い続ける

git rm --cached .

すべてを削除してやり直します。しかし、add .再帰的ではあるが再帰するrm必要があることが判明したため、機能しませんでした-r。はぁ。

git rm -r --cached .

さて、今は始めたところに戻りました。次回-nは、予行演習を行い、何が追加されるかを確認するために使用します。

git add -n .

何も破壊git help rmし--cachedないこと（そしてスペルを間違えた場合）について信頼する前に、すべてを安全な場所に圧縮しました。

入力した場合：

git status

Gitは、ステージングを解除する方法など、ステージングされているものなどを通知します。

use "git reset HEAD <file>..." to unstage

Gitは、このような状況で正しいことをするように私を微調整するかなり良い仕事をしています。

注：最近のGitバージョン（1.8.4.x）では、このメッセージが変更されています。

(use "git rm --cached <file>..." to unstage)

明確にするために：git add現在の作業ディレクトリからステージング領域に変更を移動します（インデックス）に。

このプロセスはステージングと呼ばれます。したがって、変更（変更されたファイル）をステージングする最も自然なコマンドは明白なものです。

git stage

git add タイプしやすいエイリアスです git stage

残念ながら、コマンドもありませgit unstageんgit unadd。関連するものを推測したり覚えたりするのは困難ですが、それはかなり明白です：

git reset HEAD --

これのエイリアスは簡単に作成できます。

git config --global alias.unadd 'reset HEAD --'
git config --global alias.unstage 'reset HEAD --'

そして最後に、新しいコマンドがあります。

git add file1
git stage file2
git unadd file2
git unstage file1

個人的に私はさらに短いエイリアスを使用しています：

git a # For staging
git u # For unstaging

受け入れられた回答への追加、誤って追加されたファイルが巨大な場合、 ' git reset'を使用してインデックスから削除した後でも、それがまだスペースを占有しているように見えることにおそらく気付くでしょう.gitディレクトリの。

これは心配する必要はありません。ファイルは確かにまだリポジトリにありますが、「ルーズオブジェクト」としてのみ存在します。それは（クローン、プッシュを介して）他のリポジトリーにコピーされず、スペースは最終的に再利用されます。気になる場合は、次のコマンドを実行できます。

git gc --prune=now

更新（以下は、最も投票された回答から生じる可能性のある混乱を解消するための私の試みです）：

だから、それは本当の元に戻すですgit addどれですか？

git reset HEAD <file> ？

または

git rm --cached <file>？

厳密に言えば、そして私が誤っていないのであれば、なし。

git add 元に戻すことはできません -安全に、一般的に。

まずgit add <file>実際に何をするかを思い出してみましょう：

1. 場合<file>された以前に追跡されていない、git add キャッシュに追加され、現在の内容で、。

2. <file>がすでに追跡されている場合git add 、現在のコンテンツ（スナップショット、バージョン）をキャッシュに保存します。Gitでは、ファイルの2つの異なるバージョン（スナップショット）が2つの異なるアイテムと見なされるため、このアクションは引き続きaddと呼ばれます（単なる更新ではありません）。したがって、最終的に、新しいアイテムをキャッシュに追加しています後でコミット。

これを踏まえると、質問は少し曖昧です。

コマンドを使用して誤ってファイルを追加しました...

OPのシナリオは最初のシナリオ（追跡されていないファイル）のようです。「元に戻す」で、追跡されているアイテムからファイル（現在のコンテンツだけでなく）を削除します。この場合は、実行しても問題ありません。 git rm --cached <file>。

そして、私たちは git reset HEAD <file>。これは、両方のシナリオで機能するため、一般的に推奨されます。既に追跡されているアイテムのバージョンを誤って追加した場合にも、元に戻すことができます。

ただし、注意点が2つあります。

最初：（答えで指摘されているように）git reset HEAD機能しないシナリオは1つだけですが、git rm --cached機能します：新しいリポジトリー（コミットなし）。しかし、実際には、これは実際には無関係なケースです。

第二にgit reset HEAD 、以前にキャッシュされたファイルの内容を魔法のように回復することはできません。HEADから再同期するだけです。見当違いの場合git addが以前のステージングされたコミットされていないバージョンを上書きした、それを回復することはできません。そのため、厳密に言えば、元に戻すことはできません[*]。

例：

$ git init
$ echo "version 1" > file.txt
$ git add file.txt   # First add of file.txt
$ git commit -m 'first commit'
$ echo "version 2" > file.txt
$ git add  file.txt   # Stage (don't commit) "version 2" of file.txt
$ git diff --cached file.txt
-version 1
+version 2
$ echo "version 3" > file.txt
$ git diff  file.txt
-version 2
+version 3
$ git add  file.txt    # Oops we didn't mean this
$ git reset HEAD file.txt  # Undo?
$ git diff --cached file.txt  # No dif, of course. stage == HEAD
$ git diff file.txt   # We have irrevocably lost "version 2"
-version 1
+version 3

もちろん、新しいファイルを追加するためだけに「git add」を実行する通常の遅延ワークフロー（ケース1）に従い、commit、git commit -aコマンドを使用して新しいコンテンツを更新する場合、これはそれほど重要ではありません。

^{*（編集：上記は実質的に正しいですが、ステージングされたがコミットされずに上書きされた変更を回復するための少しハック/複雑な方法がまだある可能性があります-Johannes Matokicとiolsmitによるコメントを参照してください）}

すでに追加されているファイルを元に戻すのは、Gitを使用すると非常に簡単です。myfile.txt既に追加されているをリセットするには、次を使用します。

git reset HEAD myfile.txt

説明：

不要なファイルをステージングした後、元に戻すことができますgit reset。Headローカルのファイルの先頭であり、最後のパラメータはファイルの名前です。

これらの場合に発生する可能性のあるすべてのステップを含め、以下の画像のステップをより詳細に作成しました。

git rm --cached . -r

現在のディレクトリから追加したものすべてを再帰的に「追加解除」します

走る

git gui

手動ですべてのファイルを削除するか、すべてのファイルを選択して[ ステージングからコミット解除 ]ボタンをクリックします。

Gitには考えられるすべてのアクションのコマンドがありますが、物事を正しく行うには広範な知識が必要です。そのため、せいぜい直感に反しています...

以前に行ったこと：

• ファイルを変更して使用したgit add .、またはgit add <file>。

あなたが欲しいもの：

• インデックスからファイルを削除しますが、バージョン管理を行い、コミットされていない変更を作業コピーに残します。

  git reset head <file>
  

• ファイルをHEADから最後の状態にリセットし、変更を取り消してインデックスから削除します。

  # Think `svn revert <file>` IIRC.
  git reset HEAD <file>
  git checkout <file>
  
  # If you have a `<branch>` named like `<file>`, use:
  git checkout -- <file>

  git reset --hard HEAD単一のファイルでは機能しないため、これが必要です。

• <file>インデックスとバージョニングから削除し、バージョン管理されていないファイルを作業コピーの変更とともに保持します。

  git rm --cached <file>
  

• <file>作業コピーとバージョン管理から完全に削除します。

  git rm <file>
  

質問は明確に提起されていません。その理由は、git add2つの意味があります。

1. ステージング領域に新しいファイルを追加し、次に元に戻すgit rm --cached fileます。
2. 変更されたファイルをステージング領域に追加してから、で元に戻しgit reset HEAD fileます。

疑わしい場合は、

git reset HEAD file

それはどちらの場合でも期待されることをするからです。

警告：あなたがしなければgit rm --cached fileされたファイルに変更（リポジトリ内の前に存在していたファイル）、ファイルが上削除されますgit commit！それはまだファイルシステムに存在しますが、他の誰かがコミットをプルした場合、ファイルは作業ツリーから削除されます。

git statusファイルが新しいファイルであるか、変更されたかを通知します。

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   my_new_file.txt
    modified:   my_modified_file.txt

最初のコミット時にを使用できない場合はgit reset、「Git破産」を宣言して.gitフォルダーを削除し、最初からやり直してください

他の多くの答えに従って、あなたは使うことができます git reset

だが：

私は実際にGitコマンド（まあ、エイリアス）を追加するこの素晴らしい小さな投稿を見つけました。詳細git unaddについてはgit unaddを参照してください。

単に、

git config --global alias.unadd "reset HEAD"

今できる

git unadd foo.txt bar.txt

git add -i追加したファイルを次のコミットから削除するために使用します。例：

不要なファイルを追加する：

$ git add foo
$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]#

インタラクティブな追加を開始して、追加を元に戻します（ここでgitに入力したコマンドは、「r」（元に戻す）、「1」（リストの最初のエントリは元に戻す表示）、「return」で元に戻すモードから抜け、「q」 （終了する）：

$ git add -i
           staged     unstaged path
  1:        +1/-0      nothing foo

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> r
           staged     unstaged path
  1:        +1/-0      nothing [f]oo
Revert>> 1
           staged     unstaged path
* 1:        +1/-0      nothing [f]oo
Revert>> 
note: foo is untracked now.
reverted one path

*** Commands ***
  1: [s]tatus     2: [u]pdate     3: [r]evert     4: [a]dd untracked
  5: [p]atch      6: [d]iff       7: [q]uit       8: [h]elp
What now> q
Bye.
$

それでおしまい！ここにあなたの証明があります、「foo」が追跡されていないリストに戻ったことを示しています：

$ git status
# On branch master
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
# [...]
#       foo
nothing added to commit but untracked files present (use "git add" to track)
$

git removeまたはgit rm、--cachedフラグを使用してこれに使用できます。試してください：

git help rm

新しいプロジェクトを開始するときにこの厄介な問題を回避する方法は次のとおりです。

• 新しいプロジェクトのメインディレクトリを作成します。
• を実行しますgit init。
• .gitignoreファイルを作成します（ファイルが空であっても）。
• .gitignoreファイルをコミットします。

git resetコミットがない場合、Gitを使用することは非常に困難になります。あなたが作成した場合、あなたができることをした後、小さな初期には、ちょうど1つを有するのためにコミットgit add -Aし、git resetあなたはすべての権利を取得するために必要な回数だけ。

この方法のもう1つの利点は、後で行末の問題が発生し、すべてのファイルを更新する必要がある場合に、簡単に実行できることです。

• 最初のコミットを確認してください。これにより、すべてのファイルが削除されます。
• 次に、最新のコミットをもう一度確認してください。これにより、現在の行末設定を使用して、ファイルの新しいコピーが取得されます。

質問を投稿してからGitが進化したのかもしれません。

$> git --version
git version 1.6.2.1

今、あなたは試すことができます：

git reset HEAD .

これはあなたが探しているものでなければなりません。

リビジョンの指定に失敗した場合は、セパレータを含める必要があることに注意してください。私のコンソールからの例：

git reset <path_to_file>
fatal: ambiguous argument '<path_to_file>': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions

git reset -- <path_to_file>
Unstaged changes after reset:
M    <path_to_file>

（Gitバージョン1.7.5.4）

上記のように、ステージング領域から新しいファイルを削除するには（新しいファイルの場合のみ）：

git rm --cached FILE

誤って追加された新しいファイルに対してのみrm --cachedを使用してください。

特定のフォルダー（およびそのサブフォルダー）内のすべてのファイルをリセットするには、次のコマンドを使用できます。

git reset *

*コマンドを使用して、一度に複数のファイルを処理します。

git reset HEAD *.prj
git reset HEAD *.bmp
git reset HEAD *gdb*

等

入力git resetするだけで元に戻りgit add .、最後のコミット以降に入力したことがないようです。以前にコミットしたことを確認してください。

新しいファイルを作成するとしますnewFile.txt。

誤ってファイルを追加したとしますgit add newFile.txt。

コミットする前に、この追加を元に戻したいgit reset newFile.txt：

特定のファイルの場合：

• git reset my_file.txt
• git checkout my_file.txt

追加されたすべてのファイル：

• git reset。
• git checkout。

注：チェックアウトにより、ファイル内のコードが変更され、最後に更新された（コミットされた）状態に移行します。リセットはコードを変更しません。ヘッダーをリセットするだけです。

このコマンドはあなたの変更をアンスタッシュします：

git reset HEAD filename.txt

あなたも使うことができます

git add -p 

ファイルの一部を追加します。

インタラクティブモードもあります。

git add -i

ファイルの追加を解除するには、オプション3を選択します。私の場合、私はしばしば複数のファイルを追加したいのですが、インタラクティブモードでは、このような数字を使用してファイルを追加できます。これには、4、1、2、3、および5以外のすべてが必要です。

シーケンスを選択するには、1-5と入力して、1から5までのすべてを取得します。

Gitステージングファイル

元に戻すにはgit add、以下を使用します。

git reset filename

git reset filename.txt

現在のインデックスである「コミットされようとしている」領域から、filename.txtという名前のファイルを削除します。他には何も変更しません。

git add myfile.txt ＃これにより、ファイルがコミットされるリストに追加されます

このコマンドとは正反対ですが、

git reset HEAD myfile.txt  # This will undo it.

したがって、以前の状態になります。指定されたものは、追跡されていないリストに再び表示されます（以前の状態）。

指定したファイルで頭をリセットします。したがって、頭に意味がない場合は、単にリセットされます。

Sourcetreeでは、GUIを使用して簡単にこれを行うことができます。Sourcetreeがファイルのステージング解除に使用するコマンドを確認できます。

新しいファイルを作成してGitに追加しました。次に、Sourcetree GUIを使用してステージングを解除しました。これが結果です：

ファイルのステージング解除[08/12/15 10:43] git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = sourcetree reset -q-path / to / file / filename.java

Sourcetreeはreset新しいファイルをステージング解除するために使用します。

git reset filename.txt  

現在のインデックスである「コミットされようとしている」領域から、filename.txtという名前のファイルを削除します。他には何も変更しません。