Wie entferne ich eine Datei aus dem Staging-Bereich (= Index = Cache) in Git?

Question 1

BEARBEITEN Diese Frage kann auf zwei Arten verstanden werden, und die optimale Antwort ist in beiden Fällen unterschiedlich.

Frage 1: Ich habe a hinzugefügt zuvor ungetrackte Datei zum Bereitstellungsbereich. Wie kann ich diese Datei aus dem Staging-Bereich entfernen, ohne sie aus dem Dateisystem zu entfernen?

Antwort 1: Verwenden Sie den folgenden Befehl, wie in der Antwort von John Feminella beschrieben:
```
git rm --cached <file>
```
Frage 2: Ich habe a geändert Datei bereits verfolgt, und fügte meine Änderungen zum Staging-Bereich hinzu. Wie kann ich meine Änderungen aus dem Bereitstellungsbereich entfernen? Dh, wie kann ich meine Änderungen in der Datei rückgängig machen?

Antwort 2: Verwenden Sie den folgenden Befehl, wie in der Antwort von David Underhill beschrieben:
```
git reset <file>
```

Question 2

Sie wollen:

git rm --cached [file]

Wenn Sie die weglassen --cached Option, wird es auch aus dem Arbeitsbaum gelöscht. git rm ist etwas sicherer als git reset, da Sie gewarnt werden, wenn der bereitgestellte Inhalt weder mit der Spitze des Zweigs noch mit der Datei auf der Festplatte übereinstimmt. (Wenn nicht, müssen Sie hinzufügen --force.)

Question 3

Dies sollte eine für Sie aus der Staging-Umgebung entfernen (ohne die Datei zu entfernen oder anderweitig zu ändern):

git reset <file>

Question 4

git reset HEAD <file>

zum Entfernen einer bestimmten Datei aus dem Index.

und

git reset HEAD

zum Entfernen aller indizierten Dateien.

Question 5

Benutz nur git rm --cached [file] um eine Datei aus dem Index zu entfernen.

git reset <filename> kann verwendet werden, um hinzugefügte Dateien aus dem Index zu entfernen, sofern die Dateien vorhanden sind nie begangen.

% git add First.txt
% git ls-files
First.txt
% git commit -m "First"   
% git ls-files            
First.txt
% git reset First.txt
% git ls-files              
First.txt

HINWEIS: git reset First.txt hat nach dem Commit keine Auswirkung auf den Index.

Was mich zum Thema bringt git restore --staged <file>. Es kann verwendet werden, um (vermutlich nach dem ersten Commit) hinzugefügte Dateien aus dem Index zu entfernen, sofern die Dateien vorhanden sind nie begangen.

% git add Second.txt              
% git status        
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    new file:   Second.txt
% git ls-files       
First.txt
Second.txt
% git restore --staged Second.txt
% git ls-files 
First.txt
% git add Second.txt 
% git commit -m "Second"
% git status            
On branch master
nothing to commit, working tree clean
% git ls-files 
First.txt         
Second.txt
Desktop/Test% git restore --staged .
Desktop/Test% git ls-files
First.txt                   
Second.txt
Desktop/Test% git reset .                    
Desktop/Test% git ls-files
First.txt
Second.txt
% git rm --cached -r .
rm 'First.txt'
rm 'Second.txt'
% git ls-files

tl;dr Schauen Sie sich die letzten 15 Zeilen an. Wenn Sie nicht mit erstem Commit, zweitem Commit, vor Commit, nach Commit verwechselt werden wollen, verwenden Sie immer git rm --cached [file]

Question 6

Abhängig von Ihrem Arbeitsablauf kann dies die Art von Dingen sein, die Sie selten genug benötigen, dass es wenig Sinn macht, eine Befehlszeilenlösung zu finden (es sei denn, Sie arbeiten aus irgendeinem Grund ohne grafische Oberfläche).

Verwenden Sie einfach eines der GUI-basierten Tools, die die Indexverwaltung unterstützen, zum Beispiel:

git gui <-- verwendet das Tk-Windowing-Framework -- ähnlicher Stil wie gitk

git cola <-- eine modernere GUI-Oberfläche

Mit diesen können Sie Dateien per Point-and-Click in und aus dem Index verschieben. Sie unterstützen sogar das Auswählen und Verschieben von Teilen einer Datei (einzelne Änderungen) in den und aus dem Index.

Wie wäre es mit einer anderen Perspektive: Wenn Sie bei der Verwendung eines der vorgeschlagenen, eher kryptischen Befehle Fehler machen:

git rm --cached [file]
git reset HEAD <file>

… besteht die reale Chance, dass Daten verloren gehen oder zumindest schwer wiederzufinden sind. Sofern Sie dies nicht wirklich mit sehr hoher Häufigkeit tun müssen, Die Verwendung eines GUI-Tools ist wahrscheinlich sicherer.

Arbeiten ohne Index

Aufgrund der Kommentare und Abstimmungen habe ich festgestellt, dass viele Leute den Index ständig verwenden. Ich nicht. Hier ist wie:

Übertrage meine gesamte Arbeitskopie (der typische Fall): git commit -a
Committen Sie nur ein paar Dateien: git commit (list of files)

Übertragen Sie alle bis auf ein paar geänderte Dateien: git commit -a dann ändern über git gui
Grafische Überprüfung aller Änderungen an der Arbeitskopie: git difftool --dir-diff --tool=meld

Question 7

Nach meiner bescheidenen Meinung und meiner Arbeitserfahrung mit Git ist Staging Area nicht dasselbe wie Index. Ich kann mich natürlich irren, aber wie gesagt, meine Erfahrung mit der Verwendung von Git und meine Logik sagen mir, dass dieser Index eine Struktur ist, die Ihren Änderungen an Ihrem Arbeitsbereich (lokales Repository) folgt, die nicht durch Ignorieren von Einstellungen und Staging-Bereich ausgeschlossen werden ist es, Dateien zu behalten, deren Commit bereits bestätigt wurde, auch bekannt als Dateien im Index, für die der Befehl add ausgeführt wurde. Sie bemerken und erkennen diesen “kleinen” Unterschied nicht, weil Sie ihn verwenden
git commit -a -m "comment"
Hinzufügen von indizierten und zwischengespeicherten Dateien zum Stagingbereich und Festschreiben in einem Befehl oder zu häufiges Verwenden von IDEs wie IDEA dafür. Und Cache ist das, was Änderungen in indizierten Dateien speichert. Wenn Sie eine Datei aus dem Index entfernen möchten, die zuvor noch nicht zum Bereitstellungsbereich hinzugefügt wurde, passen die zuvor vorgeschlagenen Optionen zu Ihnen, aber … Wenn Sie dies bereits getan haben, müssen Sie verwenden

Git restore --staged <file>

Und bitte fragen Sie mich nicht, wo ich vor 10 Jahren war … Ich habe Sie vermisst, diese Antwort ist für weitere Generationen)