Warum gibt es zwei Möglichkeiten, eine Datei in Git aus der Staging-Umgebung zu entfernen?

Lesezeit: 12 Minuten

Warum gibt es zwei Moglichkeiten eine Datei in Git aus
Senthess

Manchmal schlägt Git vor git rm --cached um eine Datei manchmal aus der Staging-Umgebung zu entfernen git reset HEAD file. Wann sollte ich welche verwenden?

BEARBEITEN:

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
#

  • Warum? Ich würde sagen, das liegt daran, dass sich die Befehlszeilenschnittstelle von git organisch entwickelt hat und nie einer größeren Umstrukturierung unterzogen wurde, um die Dinge konsistent zu machen. (Wenn Sie anderer Meinung sind, notieren Sie wie git rm kann beides Bühne ein Streichung und auch unspektakulär ein Zusatz)

    – Roman Starkow

    12. Januar 2014 um 14:07 Uhr


  • @romkyns: Ich stimme zu, dass die Benutzeroberfläche von Git mehrere Kuriositäten aufweist, weil sie sich organisch entwickelt hat, aber eine Entfernung ist sicherlich eine umgekehrte Funktion einer Hinzufügung, also ist es nicht logisch rm rückgängig machen add? Wie denkst du rm sollte Verhalten?

    – Zaz

    25. August 2014 um 20:04 Uhr

  • Die einzige wirkliche Antwort auf Ihre Frage ist, dass direkt nach a git init es gibt kein HEAD zurückzusetzen.

    – Meilen Route

    2. Dezember 2016 um 0:43 Uhr

  • Beste Doku dazu: help.github.com/articles/change-a-remote-s-url

    – ScottyBlades

    24. Oktober 2018 um 20:09 Uhr

  • @Zaz, ich werde meine Meinung sagen. rm impliziert das Löschen in einem Unix-Kontext. Es ist nicht das Gegenteil von dem Hinzufügen zum Index. Eine Funktion zum Entfernen von Dateien sollte nicht mit Funktionen zum Ändern des Staging-Status überladen werden. Wenn es Implementierungsdetails gibt, die es bequem machen, diese zu kombinieren, deutet das einfach auf das Fehlen einer durchdachten Abstraktionsebene in Git hin, die die Benutzerfreundlichkeit deutlich machen würde.

    – Joshua Goldberg

    2. Mai 2019 um 15:30 Uhr


Warum gibt es zwei Moglichkeiten eine Datei in Git aus
Ryan Steward

git rm --cached <filePath> wird nicht inszeniert eine Datei, eigentlich führt das Entfernen der Datei(en) durch aus dem Repo (vorausgesetzt, es wurde bereits vorher festgeschrieben), lässt die Datei jedoch in Ihrem Arbeitsbaum (und hinterlässt eine nicht verfolgte Datei).

git reset -- <filePath> Wille unspektakulär alle inszenierten Änderungen für die angegebene(n) Datei(en).

Das heißt, wenn Sie verwendet haben git rm --cached Bei einer neuen Datei, die bereitgestellt wird, würde es im Grunde so aussehen, als hätten Sie sie gerade nicht bereitgestellt, da sie noch nie zuvor festgeschrieben wurde.

Aktualisieren Sie Git 2.24

In dieser neueren Version von Git können Sie verwenden git restore --staged anstatt git reset. Sehen git-Dokumente.

  • ich würde sagen git rm --cached die Datei aus der Staging-Phase entfernen, aber nicht aus dem Arbeitsverzeichnis entfernen.

    – Pierre de LESPINAY

    11. Dezember 2012 um 14:46 Uhr

  • Das Entfernen einer zum Hinzufügen bereitgestellten Datei, so dass sie nicht mehr bereitgestellt wird, kann sicherlich als „Staging einer zum Hinzufügen bereitgestellten Datei aufheben“ bezeichnet werden, richtig? Das Endergebnis ist keine schrittweise Löschungdas ist sicher, daher halte ich das Missverständnis für absolut verständlich.

    – Roman Starkow

    12. Januar 2014 um 14:16 Uhr

  • Also normalerweise würde man verwenden git rm --cached <filePath> um einige Dateien aus dem Repo zu entfernen nach dem zu erkennen, dass es nie im Repo hätte sein sollen: Führen Sie also höchstwahrscheinlich diesen Befehl aus und fügen Sie dann die relevanten Dateien hinzu gitignore. Hab ich recht?

    – Adrien Be

    2. März 2016 um 7:34 Uhr

  • Bei so vielen Stimmen sowohl für Frage als auch für Antwort würde ich sagen, dass wir anscheinend eine haben wollen unstage Befehl ein git.

    – Milosmen

    20. März 2019 um 13:19 Uhr

  • “git status” rät jetzt: Verwenden Sie “git restore –staged …”, um die Bereitstellung aufzuheben

    – Yucer

    28. August 2019 um 11:25 Uhr


git rm --cached wird verwendet, um eine Datei aus dem Index zu entfernen. Falls sich die Datei bereits im Repo befindet, git rm --cached entfernt die Datei aus dem Index und belässt sie im Arbeitsverzeichnis, und ein Commit entfernt sie nun auch aus dem Repo. Grundsätzlich hätten Sie nach dem Commit die Datei unversioniert und eine lokale Kopie behalten.

git reset HEAD file (was standardmäßig die --mixed Flag) unterscheidet sich darin, dass in dem Fall, in dem sich die Datei bereits im Repo befindet, die Indexversion der Datei durch die aus dem Repo (HEAD) ersetzt wird, wodurch die Staging-Funktion effektiv aufgehoben wird Modifikationen dazu.

Im Fall einer unversionierten Datei wird die gesamte Datei aus der Staging-Umgebung entfernt, da die Datei nicht im HEAD vorhanden war. In dieser Ansicht git reset HEAD file und git rm --cached sind gleich, aber sie sind nicht gleich (wie im Fall von Dateien bereits im Repo erklärt)

Zur Frage nach Why are there 2 ways to unstage a file in git? – Es gibt nie wirklich nur einen Weg, irgendetwas in Git zu tun. das ist das schöne daran 🙂

  • Sowohl die akzeptierte als auch diese Antwort sind großartig und erklären, warum Sie die eine gegen die andere verwenden würden. Aber sie beantworten nicht direkt die implizite Frage nach warum schlägt git zwei verschiedene Methoden vor. Im ersten Fall im OP-Beispiel wurde gerade ein Git-Init durchgeführt. In diesem Fall schlägt git “git rm –cached” vor, da zu diesem Zeitpunkt keine Commits im Repository vorhanden sind und HEAD daher nicht gültig ist. “git reset HEAD — a” erzeugt: “fatal: Fehler beim Auflösen von ‘HEAD’ als gültige Referenz.”

    – rußnuß

    16. August 2014 um 13:56 Uhr


  • Würden Sie mit ‘git checkout’ nicht alle Änderungen verlieren, die Sie an der Datei vorgenommen haben? Das ist nicht dasselbe wie das Unstaging einer Datei, es sei denn, ich verstehe das nicht.

    – John Deighan

    21. September 2017 um 0:33 Uhr

  • there is never really only one way to do anything in git. that is the beauty of it – Hmm warum ? Es ist immer toll, wenn es nur einen offensichtlichen Weg gibt. das spart viel Zeit und Gedächtnis im Gehirn ))

    – Oto Schawadse

    3. Dezember 2019 um 12:24 Uhr


Warum gibt es zwei Moglichkeiten eine Datei in Git aus
waldreich

Recht einfach:

  • git rm --cached <file> bewirkt, dass Git die Verfolgung der Datei vollständig beendet (Lassen Sie es im Dateisystem, im Gegensatz zu plain git rm*)
  • git reset HEAD <file> macht alle Änderungen rückgängig, die seit dem letzten Commit an der Datei vorgenommen wurden (setzt sie aber nicht im Dateisystem zurück, im Gegensatz zu dem, was der Befehlsname vermuten lässt**). Die Datei bleibt unter Revisionskontrolle.

Wenn sich die Datei vorher nicht in der Revisionskontrolle befand (d. h. Sie entstagen eine Datei, die Sie gerade hatten git added zum ersten Mal), dann haben die beiden Befehle die gleiche Wirkung, daher der Anschein, als seien dies “zwei Möglichkeiten, etwas zu tun”.

* Beachten Sie die Einschränkung, die @DrewT in seiner Antwort erwähnt, bzgl git rm --cached einer Datei, die war zuvor begangen zum Depot. Im Zusammenhang mit dieser Frage einer gerade hinzugefügten und noch nicht festgeschriebenen Datei gibt es keinen Grund zur Sorge.

** Ich hatte peinlich lange Angst, den Befehl git reset wegen seines Namens zu verwenden – und noch heute schlage ich oft die Syntax nach, um sicherzustellen, dass ich nichts vermassele. (aktualisieren: Endlich habe ich mir die Zeit genommen fassen die Verwendung von zusammen git reset auf einer tldr-Seitealso habe ich jetzt ein besseres mentales Modell dafür, wie es funktioniert, und eine schnelle Referenz, falls ich ein Detail vergessen sollte.)

  • Es ist git rm <file> --cached

    – Neonkamerad

    10. Juli 2015 um 9:25 Uhr

  • Ich glaube wirklich nicht, dass die Bearbeitung dieser Antwort vom 4. August 2015 eine allgemeine Verbesserung war. Es könnte die technische Korrektheit behoben haben (ich fühle mich nicht qualifiziert, das zu bewerten), aber ich fürchte, es hat den Ton der Antwort viel weniger zugänglich gemacht, indem es eine Sprache wie „unset the imperative to begin to track a aktuell-untracked file “, und mit Fachjargon wie „index“ und „HEAD“, genau das Zeug, das Anfänger abschreckt. Wenn jemand kann, bearbeiten Sie bitte, um eine anfängerfreundlichere Sprache wiederherzustellen.

    – waldreich

    12. August 2015 um 17:50 Uhr


  • Stimme @waldyrous zu. Die ursprüngliche Antwort stammte möglicherweise nicht direkt aus dem Git-Lehrbuch, beantwortete die Frage jedoch auf einem ausreichenden technischen Niveau. Technische Details hätten in Kommentaren geklärt werden sollen, nicht als Bearbeitung, die die ursprüngliche Absicht verschleiert.

    – Simon Robb

    19. Oktober 2015 um 0:38 Uhr

  • Ich habe die Bearbeitung rückgängig gemacht. Ich glaube, die Community hat (in den vorherigen Kommentaren und den Abstimmungen darüber) ausreichend bestätigt, dass die Bearbeitung die Klarheit der Antwort beeinträchtigt hat.

    – waldreich

    26. Juli 2016 um 15:52 Uhr

  • Beachten Sie, dass @DrewT bei der Verwendung warnt rm --cached und drücken, wird jeder, der denselben Zweig zieht, die Datei(en) tatsächlich aus seinem Arbeitsbaum entfernen.

    – Tom Hale

    3. August 2016 um 12:57 Uhr

1646321900 170 Warum gibt es zwei Moglichkeiten eine Datei in Git aus
Daniel Alder

Dieser Thread ist etwas alt, aber ich möchte trotzdem eine kleine Demonstration hinzufügen, da es immer noch kein intuitives Problem ist:

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 (ohne -q) gibt eine Warnung über die geänderte Datei aus und ihr Exit-Code ist 1, was als Fehler in einem Skript betrachtet wird.

Bearbeiten: git checkout HEAD to-be-modified to-be-removed funktioniert auch für das Unstaging, entfernt die Änderung jedoch vollständig aus dem Arbeitsbereich

git 2.23.0 aktualisieren: Von Zeit zu Zeit ändern sich die Befehle. Jetzt, git status sagt:

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

… was für alle drei Arten von Änderungen funktioniert

1646321901 883 Warum gibt es zwei Moglichkeiten eine Datei in Git aus
ives

Wenn Sie versehentlich Dateien bereitgestellt haben, die Sie nicht festschreiben möchten, und sicher sein möchten, dass Sie die Änderungen behalten, können Sie auch Folgendes verwenden:

git stash
git stash pop

Dadurch wird HEAD zurückgesetzt und Ihre Änderungen werden erneut angewendet, sodass Sie einzelne Dateien zum Commit erneut bereitstellen können. Dies ist auch hilfreich, wenn Sie vergessen haben, einen Feature-Branch für Pull-Requests zu erstellen (git stash ; git checkout -b <feature> ; git stash pop).

  • Dies ist eine saubere Lösung und viel weniger besorgniserregend als die Eingabe von “git rm”.

    – Unterbild

    18. Juli 2017 um 21:47 Uhr

  • git stash hat weitere damit verbundene Vorteile, da es Einträge im Reflog erstellt, die dann in Zukunft verfügbar sind. Wenn Sie Zweifel haben, gehen Sie vor und tun Sie a git stash (z.B git stash save -u "WIP notes to self" (Das ‘-u’ soll alle neuen/unverfolgten Dateien in den Stash-Commit aufnehmen) … dann versuchen Sie es git reflog show stash , um die Liste der Stash-Commits und ihrer Shas anzuzeigen. Ich empfehle einen Shell-Alias ​​wie alias grs="git reflog show stash"

    – wöchentlich

    12. Februar 2019 um 18:32 Uhr

Diese 2 Befehle haben mehrere subtile Unterschiede, wenn sich die betreffende Datei bereits im Repo befindet und unter Versionskontrolle steht (zuvor festgeschrieben usw.):

  • git reset HEAD <file> entstagt die Datei im aktuellen Commit.
  • git rm --cached <file> wird die Datei auch für zukünftige Commits aus der Staging-Umgebung entfernen. Es ist nicht inszeniert, bis es wieder mit hinzugefügt wird git add <file>.

Und es gibt noch einen wichtigen Unterschied:

  • Nach dem Rennen git rm --cached <file> und schieben Sie Ihren Zweig auf die Fernbedienung, jeder, der Ihren Zweig von der Fernbedienung zieht, erhält die Datei EIGENTLICH aus ihrem Ordner gelöscht, obwohl die Datei in Ihrem lokalen Arbeitsset nur nicht verfolgt wird (dh nicht physisch aus dem Ordner gelöscht wird).

Dieser letzte Unterschied ist wichtig für Projekte, die eine Konfigurationsdatei enthalten, in der jeder Entwickler im Team eine andere Konfiguration hat (dh eine andere Basis-URL, IP- oder Port-Einstellung), also wenn Sie verwenden git rm --cached <file> Jeder, der Ihren Zweig zieht, muss die Konfiguration manuell neu erstellen, oder Sie können ihm Ihre senden und er kann es wieder auf seine IP-Einstellungen (usw.) zurücksetzen, da das Löschen nur Personen betrifft, die Ihren Zweig von der Fernbedienung ziehen .

  • Dies ist eine saubere Lösung und viel weniger besorgniserregend als die Eingabe von “git rm”.

    – Unterbild

    18. Juli 2017 um 21:47 Uhr

  • git stash hat weitere damit verbundene Vorteile, da es Einträge im Reflog erstellt, die dann in Zukunft verfügbar sind. Wenn Sie Zweifel haben, gehen Sie vor und tun Sie a git stash (z.B git stash save -u "WIP notes to self" (Das ‘-u’ soll alle neuen/unverfolgten Dateien in den Stash-Commit aufnehmen) … dann versuchen Sie es git reflog show stash , um die Liste der Stash-Commits und ihrer Shas anzuzeigen. Ich empfehle einen Shell-Alias ​​wie alias grs="git reflog show stash"

    – wöchentlich

    12. Februar 2019 um 18:32 Uhr

1646321902 277 Warum gibt es zwei Moglichkeiten eine Datei in Git aus
Jiminikiz

Sagen wir Sie stage ein ganzes Verzeichnis über git add <folder>aber Sie möchten eine Datei aus der bereitgestellten Liste ausschließen (dh der Liste, die beim Ausführen generiert wird git status) und behalten die Änderungen in der ausgeschlossenen Datei (Sie haben an etwas gearbeitet und es ist noch nicht fertig zum Commit, aber Sie möchten Ihre Arbeit nicht verlieren …). Sie könnten einfach verwenden:

git reset <file>

Wenn du rennst git statusSie werden sehen, dass alle Datei(en) Sie reset sind unstaged und den Rest der Dateien Sie added sind noch im staged Liste.

  • idk, warum alle anderen so viel Komplexität mögen. Dies ist eine gute Antwort.

    – ScottyBlades

    7. Juni 2021 um 21:38 Uhr


924860cookie-checkWarum gibt es zwei Möglichkeiten, eine Datei in Git aus der Staging-Umgebung zu entfernen?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy