Vraag Hoe maak je 'git add' ongedaan voordat je commit?


Ik heb ten onrechte bestanden toegevoegd aan git met behulp van de opdracht:

git add myfile.txt

Ik heb nog niet gelopen git commit. Is er een manier om dit ongedaan te maken, zodat deze bestanden niet worden opgenomen in de commit?


Er zijn tot nu toe 48 antwoorden (sommige zijn verwijderd). Voeg geen nieuwe toe, tenzij u nieuwe informatie heeft.


7450
2017-12-07 21:57


oorsprong


antwoorden:


U kunt ongedaan maken git add voordat je commit

git reset <file>

die het zal verwijderen uit de huidige index (de lijst "about to be committed") zonder iets anders te veranderen.

Je kunt gebruiken

git reset

zonder een bestandsnaam om alle gewenste wijzigingen ongedaan te maken. Dit kan van pas komen als er te veel bestanden zijn die een voor een binnen een redelijke tijd kunnen worden vermeld.

In oude versies van Git zijn de bovenstaande commando's gelijk aan git reset HEAD <file> en git reset HEAD respectievelijk, en zal falen als HEAD is undefined (omdat je nog geen commits in je repo hebt gemaakt) of dubbelzinnig (omdat je een tak hebt gemaakt met de naam HEAD, wat een stom ding is dat je niet zou moeten doen). Deze is gewijzigd in Git 1.8.2In moderne versies van Git kun je echter de bovenstaande commando's gebruiken voordat je je eerste commit hebt gemaakt:

"git reset" (zonder opties of parameters) gebruikt om te fout wanneer      je hebt geen commits in je geschiedenis, maar het geeft je nu      een lege index (om niet-bestaande commit aan te passen waar je niet eens aan zit).


8357
2017-12-07 22:30



Jij wil:

git rm --cached <added_file_to_undo>

Redenering:

Toen ik nieuw was, heb ik het eerst geprobeerd

git reset .

(om mijn volledige aanvankelijke toevoeging ongedaan te maken), alleen om dit (niet zo) nuttige bericht te krijgen:

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

Het blijkt dat dit komt omdat de HEAD-ref (filiaal?) Pas na de eerste commit bestaat. Dat wil zeggen, je zult tegen hetzelfde probleem van de beginner als ik aanlopen als je workflow, zoals de mijne, ongeveer zoiets was als:

  1. cd naar mijn geweldige nieuwe projectdirectory om Git, de nieuwe hotness, uit te proberen
  2. git init
  3. git add .
  4. git status

    ... veel onzinrollen door ...

    => Verdomme, ik wilde dat niet allemaal toevoegen.

  5. google "git add ongedaan maken"

    => vind Stack Overflow - yay

  6. git reset .

    => fataal: kon 'HEAD' niet oplossen als een geldige referentie.

Het blijkt verder dat er is een fout gelogd tegen het niet helpen van dit in de mailinglijst.

En dat de juiste oplossing daar was in de Git-statusoutput (die, ja, ik verdoezelde als 'rotzooi')

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

En de oplossing is inderdaad om te gebruiken git rm --cached FILE.

Let op de waarschuwingen elders hier - git rm verwijdert uw lokale werkkopie van het bestand, maar niet als je gebruikt --cached. Hier is het resultaat van git help rm:

--cached       Gebruik deze optie om paden op te heffen en paden alleen uit de index te verwijderen.       Werkende boomstructuren, al dan niet gewijzigd, blijven bestaan.

Ik ga verder met gebruiken

git rm --cached .

om alles te verwijderen en opnieuw te beginnen. Werkte echter niet, omdat terwijl add . is recursief, blijkt rm behoefte aan -r recurse. Zucht.

git rm -r --cached .

Oké, nu ben ik terug naar waar ik begon. De volgende keer dat ik ga gebruiken -n om een ​​droge run te doen en te zien wat er zal worden toegevoegd:

git add -n .

Ik ritste alles op een veilige plaats voordat ik het vertrouwde git help rm over de --cached niets vernietigen (en wat als ik het verkeerd spelde).


1950
2018-03-25 16:20



Als u typt:

git status

git zal je vertellen wat er geënsceneerd wordt, enz., inclusief instructies over het unstage:

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

Ik vind dat Git best een goede manier is om me in deze situaties de juiste dingen te laten doen.

Opmerking: Recente git-versies (1.8.4.x) hebben dit bericht gewijzigd:

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

484
2017-12-07 23:22



Verduidelijken: git add verplaatst wijzigingen van de huidige werkdirectory naar de verzamelplaats (inhoudsopgave).

Dit proces wordt genoemd regie. Dus het meest natuurlijke commando om stadium de wijzigingen (gewijzigde bestanden) liggen voor de hand:

git stage

git add is gewoon een eenvoudiger te typen alias voor git stage

Jammer dat er geen is git unstage noch git unadd commando's. De relevante is moeilijker te raden of te herinneren, maar is vrij duidelijk:

git reset HEAD --

We kunnen eenvoudig een alias hiervoor maken:

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

En tot slot hebben we nieuwe opdrachten:

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

Persoonlijk gebruik ik nog kortere aliassen:

git a #for staging
git u #for unstaging

220
2017-09-10 20:28



Een toevoeging op het geaccepteerde antwoord, als je ten onrechte toegevoegde bestand enorm was, zul je waarschijnlijk merken dat, zelfs na het verwijderen van de index met 'git reset', het lijkt nog steeds ruimte in te nemen in de .git directory. Dit is niets om je zorgen over te maken, het bestand bevindt zich inderdaad nog steeds in de repository, maar alleen als een "los object", het zal niet naar andere repositories gekopieerd worden (via kloon, push), en de ruimte zal uiteindelijk worden teruggewonnen - hoewel misschien niet erg snel. Als je angstig bent, kun je het volgende uitvoeren:

git gc --prune=now

Bijwerken (wat volgt is mijn poging om enige verwarring weg te nemen die kan voortvloeien uit de meest up-gestemde antwoorden):

Dus, dat is het echte ongedaan maken van git add?

git reset HEAD <file> ?

of

git rm --cached <file>?

Strikt genomen, en als ik me niet vergis: geen.

git add  kan niet ongedaan gemaakt worden - veilig, in het algemeen.

Laten we eerst herinneren wat git add <file> eigenlijk doet:

  1. Als <file> was niet eerder bijgehouden, git add  voegt het toe aan de cache, met de huidige inhoud.

  2. Als <file> was al bijgehouden, git add  slaat de huidige inhoud op (snapshot, versie) naar de cache. In GIT wordt deze actie nog steeds genoemd toevoegen, (niet alleen bijwerken it), omdat twee verschillende versies (snapshots) van een bestand als twee verschillende items worden beschouwd: daarom voegen we inderdaad een nieuw item toe aan de cache, om uiteindelijk later te committen.

In het licht hiervan is de vraag enigszins dubbelzinnig:

Ik heb ten onrechte bestanden toegevoegd met de opdracht ...

Het scenario van de OP lijkt de eerste (niet-gevonden bestand), we willen dat het "ongedaan maken" het bestand (niet alleen de huidige inhoud) uit de bijgehouden items verwijdert. Als dit is het geval, dan is het OK om te rennen git rm --cached <file>.

En we kunnen ook rennen git reset HEAD <file>. Dit heeft over het algemeen de voorkeur, omdat het in beide scenario's werkt: het doet ook het ongedaan maken toen we ten onrechte een versie van een reeds bijgehouden item toevoegden.

Maar er zijn twee voorbehouden.

Ten eerste: er is (zoals in het antwoord wordt opgemerkt) slechts één scenario waarin git reset HEAD werkt niet, maar git rm --cached doet: een nieuwe repository (geen commits). Maar eigenlijk is dit een praktisch irrelevante zaak.

Ten tweede: wees je ervan bewust git reset HEAD  kan de eerder in de cache opgeslagen inhoud van het bestand niet op magische wijze herstellen, maar het wordt gewoon opnieuw gesynchroniseerd vanuit de HEAD. Als onze misleide git add een niet eerder gecommandeerde niet-gecommitteerde versie overschrijven, we kunnen deze niet herstellen. Daarom kunnen we strikt genomen niet ongedaan maken.

Voorbeeld:

$ 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 lost irrevocably "version 2"
-version 1
+version 3

Natuurlijk is dit niet erg kritiek als we gewoon de gebruikelijke luie workflow volgen van het doen van 'git add' alleen voor het toevoegen van nieuwe bestanden (case 1), en we updaten nieuwe content via de commit, git commit -a opdracht.


136
2018-05-18 18:05



git rm --cached . -r

zal alles wat u uit uw huidige map hebt toegevoegd, recursief "verwijderen"


85
2017-12-09 21:19



Rennen

git gui

en verwijder alle bestanden handmatig of door ze allemaal te selecteren en op de te klikken onstage van commit knop.


77
2017-10-12 01:12



Git heeft commando's voor elke denkbare actie, maar heeft uitgebreide kennis nodig om dingen goed te krijgen en daarom is het op zijn best contra-intuïtief ...

Wat je eerder deed:

  • Een bestand gewijzigd en gebruikt git add .of git add <file>.

Wat je wilt:

  • Verwijder het bestand uit de index, maar houd het in versieversie en vertrokken met niet-gecommiteerde wijzigingen in werkkopie:

    git reset head <file>
    
  • Reset het bestand naar de laatste status vanuit HEAD, ongedaan maken van wijzigingen en verwijderen uit de index:

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

    Dit is sindsdien nodig git reset --hard HEAD werkt niet met afzonderlijke bestanden.

  • Verwijderen <file> van indexeren en versiebeheer, waarbij het niet-versiebestand behouden blijft met wijzigingen in werkkopie:

    git rm --cached <file>
    
  • Verwijderen <file> van werkkopie en versiebeheer volledig:

    git rm <file>
    

73
2018-03-29 11:14



De vraag is niet duidelijk gesteld. De reden is dat git add heeft twee betekenissen:

  1. toevoegen van een nieuw bestand naar het verzamelgebied en maak vervolgens ongedaan met git rm --cached file.
  2. toevoegen van een gemodificeerde bestand naar het verzamelgebied en vervolgens ongedaan maken met git reset HEAD file.

gebruik bij twijfel

git reset HEAD file

Omdat het in beide gevallen het verwachte doet.

Waarschuwing: als je dat doet git rm --cached file op een bestand dat was gemodificeerde (een bestand dat eerder bestond in de repository), waarna het bestand wordt verwijderd git commit! Het zal nog steeds bestaan ​​in uw bestandssysteem, maar als iemand anders uw commit haalt, wordt het bestand uit hun werkboom verwijderd.

git status zal je vertellen of het bestand een was nieuw bestand of gemodificeerde:

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

62
2018-01-16 19:54



ongedaan maken een bestand dat al is toegevoegd, is vrij eenvoudig te gebruiken git, voor het resetten myfile.txt die al zijn toegevoegd, gebruik:

git reset HEAD myfile.txt

Leg uit:

Nadat je ongewenste bestand (en) hebt geënsceneerd, kun je het ongedaan maken git reset, Head is kop van uw bestand in lokale en de laatste parameter is de naam van uw bestand.

Ik maak de stappen in de onderstaande afbeelding voor meer informatie voor u, inclusief alle stappen die in deze gevallen kunnen worden uitgevoerd:

git reset HEAD


60
2018-06-28 10:43