Jak cofnąć polecenie „dodaj git” przed zatwierdzeniem?

Przez pomyłkę dodałem pliki do Gita, używając polecenia:

git add myfile.txt

Jeszcze nie uciekłem git commit. Czy istnieje sposób, aby to cofnąć, aby te pliki nie zostały uwzględnione w zatwierdzeniu?

Możesz cofnąć git addprzed zatwierdzeniem za pomocą

git reset <file>

co spowoduje usunięcie go z bieżącego indeksu (listy „wkrótce do zatwierdzenia”) bez zmiany czegokolwiek innego.

Możesz użyć

git reset

bez żadnej nazwy pliku, aby wycofać wszystkie należne zmiany. Może się to przydać, gdy w rozsądnym czasie jest zbyt wiele plików, aby można je było wyświetlać pojedynczo.

W starych wersjach Gita powyższe polecenia są odpowiednio równoważne git reset HEAD <file>i git reset HEAD, i nie powiedzie się, jeśli nie zostaną HEADzdefiniowane (ponieważ nie dokonano jeszcze żadnych zatwierdzeń w repozytorium) lub niejednoznaczne (ponieważ utworzono gałąź o nazwie HEAD, co jest głupią rzeczą których nie powinieneś robić). Zostało to zmienione w Git 1.8.2 , więc we współczesnych wersjach Git możesz używać powyższych poleceń nawet przed pierwszym zatwierdzeniem:

„git reset” (bez opcji lub parametrów) używał do błędu, gdy nie masz żadnych zatwierdzeń w historii, ale teraz daje ci pusty indeks (aby dopasować nieistniejące zatwierdzenie, którego nawet nie używasz).

Chcesz:

git rm --cached <added_file_to_undo>

Rozumowanie:

Kiedy byłem nowy, po raz pierwszy spróbowałem

git reset .

(aby cofnąć całe moje początkowe dodawanie), tylko po to, aby otrzymać tę (nie taką) pomocną wiadomość:

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

Okazuje się, że dzieje się tak, ponieważ HEAD ref (gałąź?) Nie istnieje aż do pierwszego zatwierdzenia. Oznacza to, że napotkasz ten sam problem dla początkujących, co ja, jeśli Twój przepływ pracy, podobnie jak mój, był podobny:

1. cd do mojego wspaniałego nowego katalogu projektu, aby wypróbować Git, nową popularność
2. git init
3. git add .

4. git status

   ... mnóstwo bzdur przewija się przez ...

   => Cholera, nie chciałem tego wszystkiego dodawać.

5. google „cofnij dodanie git”

   => znajdź przepełnienie stosu - yay

6. git reset .

   => fatal: Nie można rozpoznać „HEAD” jako prawidłowego numeru referencyjnego.

Okazuje się ponadto, że na liście mailowej zarejestrowano błąd przeciwko nieużyteczności tego.

I że poprawne rozwiązanie znalazło się właśnie w danych wyjściowych statusu Git (które, tak, ja przekląłem jako „bzdura”)

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

A rozwiązaniem jest rzeczywiście użyć git rm --cached FILE.

Zwróć uwagę na ostrzeżenia w innym miejscu tutaj - git rmusuwa lokalną kopię roboczą pliku, ale nie w przypadku użycia - buforowanej . Oto wynik git help rm:

--cached Użyj tej opcji, aby wycofać scenę i usunąć ścieżki tylko z indeksu. Pliki drzewa roboczego, zmodyfikowane lub nie, zostaną pozostawione.

Kontynuuję używanie

git rm --cached .

usunąć wszystko i zacząć od nowa. Nie działało jednak, ponieważ chociaż add .jest rekurencyjne, okazuje się, że rmtrzeba -rsię powtórzyć. Westchnienie.

git rm -r --cached .

Okej, teraz wracam do miejsca, gdzie zacząłem. Następnym razem zamierzam użyć -nsuchego biegu i zobaczyć, co zostanie dodane:

git add -n .

Spakowałam wszystko do bezpiecznego miejsca, zanim ufałam, git help rmże --cachedniczego nie niszczysz (a co, jeśli źle to przeliteruję).

Jeśli wpiszesz:

git status

Git powie ci, co jest inscenizowane itp., W tym instrukcje, jak się wycofać:

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

Uważam, że Git wykonuje niezłą robotę, nakłaniając mnie do robienia właściwych rzeczy w takich sytuacjach.

Uwaga: Najnowsze wersje Git (1.8.4.x) zmieniły ten komunikat:

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

Aby to wyjaśnić: git addprzenosi zmiany z bieżącego katalogu roboczego do obszaru pomostowego (indeksu).

Ten proces nazywa się inscenizacją . Tak więc większość poleceń naturalny etap zmian (zmiana plików) jest oczywista:

git stage

git add jest po prostu łatwiejszym do wpisania aliasem git stage

Szkoda, że ​​nie ma git unstageani git unaddpoleceń. Odpowiedni trudniej zgadnąć lub zapamiętać, ale jest dość oczywisty:

git reset HEAD --

Możemy łatwo stworzyć dla tego alias:

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

I wreszcie, mamy nowe polecenia:

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

Osobiście używam jeszcze krótszych aliasów:

git a # For staging
git u # For unstaging

Dodatek do zaakceptowanej odpowiedzi, jeśli Twój błędnie dodany plik był ogromny, prawdopodobnie zauważysz, że nawet po usunięciu go z indeksu za pomocą „ git reset” nadal wydaje się, że zajmuje on miejsce w .gitkatalogu.

Nie ma się czym martwić; plik jest rzeczywiście nadal w repozytorium, ale tylko jako „luźny obiekt”. Nie zostanie skopiowany do innych repozytoriów (przez klonowanie, wypychanie), a przestrzeń zostanie ostatecznie odzyskana - choć może nie wkrótce. Jeśli jesteś niespokojny, możesz uruchomić:

git gc --prune=now

Aktualizacja (następująca jest moja próba usunięcia pewnych nieporozumień, które mogą wyniknąć z najbardziej uprzywilejowanych odpowiedzi):

Więc, co jest prawdziwym cofania z git add?

git reset HEAD <file> ?

lub

git rm --cached <file>?

Ściśle mówiąc, a jeśli się nie mylę: brak .

git add nie można tego cofnąć - ogólnie bezpiecznie.

Przypomnijmy najpierw, co git add <file>właściwie robi:

1. Jeśli nie<file> był wcześniej śledzony , git add dodaje go do pamięci podręcznej z bieżącą zawartością.

2. Jeśli <file>było już śledzone , git add zapisuje bieżącą zawartość (migawkę, wersję) w pamięci podręcznej. W Git ta czynność jest nadal nazywana dodawaniem (a nie tylko aktualizacją ), ponieważ dwie różne wersje (migawki) pliku są traktowane jako dwa różne elementy: dlatego rzeczywiście dodajemy nowy element do pamięci podręcznej, aby ostatecznie popełnione później.

W świetle tego pytanie jest nieco dwuznaczne:

Pomyłkowo dodałem pliki za pomocą polecenia ...

Scenariusz PO wydaje się być pierwszym (nieśledzony plik), chcemy, aby „cofnięcie” usunęło plik (nie tylko bieżącą zawartość) ze śledzonych elementów. W takim przypadku można uruchomić git rm --cached <file>.

I moglibyśmy także biec git reset HEAD <file>. Jest to na ogół preferowane, ponieważ działa w obu scenariuszach: wykonuje również cofanie, gdy błędnie dodaliśmy wersję już śledzonego elementu.

Ale są dwa zastrzeżenia.

Po pierwsze: istnieje (jak wskazano w odpowiedzi) tylko jeden scenariusz, w którym git reset HEADnie działa, ale git rm --cacheddziała: nowe repozytorium (bez zatwierdzeń). Ale tak naprawdę jest to praktycznie nieistotny przypadek.

Po drugie: pamiętaj, że git reset HEAD nie można magicznie odzyskać wcześniej buforowanej zawartości pliku, po prostu ponownie synchronizuje go z HEAD. Jeśli nasz wprowadzony w błąd git addnadpisał poprzednią zainscenizowaną niezaangażowaną wersję, nie możemy jej odzyskać. Właśnie dlatego, ściśle mówiąc, nie możemy cofnąć [*].

Przykład:

$ 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

Oczywiście nie ma to większego znaczenia, jeśli postępujemy zgodnie ze zwykłym leniwym obiegiem pracy polegającym na wykonywaniu polecenia „git add” tylko w celu dodawania nowych plików (przypadek 1) i aktualizujemy nową zawartość za pomocą git commit -apolecenia zatwierdzenia .

^{* (Edycja: powyższe jest praktycznie poprawne, ale nadal mogą istnieć pewne nieco zhackowane / skomplikowane sposoby odzyskiwania zmian, które zostały wprowadzone, ale nie zostały zatwierdzone, a następnie zastąpione - patrz komentarze Johannesa Matokica i iolsmit)}

Cofanie pliku, który został już dodany, jest dość łatwe przy użyciu Git. Aby zresetować myfile.txt, które zostały już dodane, użyj:

git reset HEAD myfile.txt

Wyjaśnienie:

Po umieszczeniu niechcianych plików, możesz je cofnąć git reset. Headjest głową pliku w lokalnym pliku, a ostatnim parametrem jest nazwa pliku.

Stworzyłem dla Ciebie szczegółowe kroki na obrazku poniżej, w tym wszystkie kroki, które mogą się zdarzyć w następujących przypadkach:

git rm --cached . -r

usunie rekursywnie wszystko, co dodałeś z bieżącego katalogu

Biegać

git gui

i usuń wszystkie pliki ręcznie lub przez wybranie ich wszystkich i kliknięcie przycisku wycofania z zatwierdzenia .

Git ma polecenia dla każdej możliwej akcji, ale potrzebuje rozległej wiedzy, aby wszystko było dobrze, dlatego jest co najmniej intuicyjny ...

Co robiłeś wcześniej:

• Zmieniono plik i wykorzystano git add ., lub git add <file>.

Czego chcesz:

• Usuń plik z indeksu, ale zachowaj jego wersję i pozostaw niezatwierdzone zmiany w kopii roboczej:

  git reset head <file>
  

• Zresetuj plik do ostatniego stanu z poziomu HEAD, cofając zmiany i usuwając je z indeksu:

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

  Jest to potrzebne, ponieważ git reset --hard HEADnie działa z pojedynczymi plikami.

• Usuń <file>z indeksu i wersji, zachowując niewersjonowany plik ze zmianami w kopii roboczej:

  git rm --cached <file>
  

• <file>Całkowicie usuń z kopii roboczej i wersji:

  git rm <file>
  

Pytanie nie jest jasno postawione. Powodem jest to, że git addma dwa znaczenia:

1. dodając nowy plik do obszaru pomostowego, a następnie cofnij za pomocągit rm --cached file .
2. dodając zmodyfikowany plik do obszaru pomostowego, a następnie cofnij za pomocą git reset HEAD file.

W razie wątpliwości użyj

git reset HEAD file

Ponieważ w obu przypadkach spełnia oczekiwane oczekiwania.

Ostrzeżenie: jeśli zrobisz to git rm --cached filena pliku, który został zmodyfikowany (plik, który istniał wcześniej w repozytorium), plik zostanie usunięty git commit! Wciąż będzie istniał w twoim systemie plików, ale jeśli ktoś inny ściągnie twoje zatwierdzenie, plik zostanie usunięty z drzewa pracy.

git statuspoinformuje Cię, czy plik był nowym plikiem, czy zmodyfikowany :

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

Jeśli jesteś przy pierwszym zatwierdzeniu i nie możesz użyć git reset, po prostu zadeklaruj „bankructwo Git”, usuń .gitfolder i zacznij od nowa

Jak na wiele innych odpowiedzi, możesz użyć git reset

ALE:

Znalazłem ten świetny mały post, który faktycznie dodaje polecenie Git (cóż, alias) dla git unadd: zobacz git unadd lub…

Po prostu,

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

Teraz możesz

git unadd foo.txt bar.txt

Służy git add -ido usuwania właśnie dodanych plików z nadchodzącego zatwierdzenia. Przykład:

Dodanie pliku, którego nie chciałeś:

$ 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)
# [...]#

Przechodzenie do interaktywnego dodawania w celu cofnięcia dodawania (polecenia wpisywane w git tutaj to „r” (cofnij), „1” (pierwszy wpis na liście pokazuje cofnięcie), „return”, aby wyjść z trybu przywracania i „q” (porzucić):

$ 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.
$

Otóż ​​to! Oto twój dowód pokazujący, że „foo” powraca na nieśledzoną listę:

$ 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 removelub git rmmożna do tego użyć --cachedflagi. Próbować:

git help rm

Oto sposób na uniknięcie tego irytującego problemu podczas rozpoczynania nowego projektu:

• Utwórz katalog główny dla nowego projektu.
• Uruchom git init.
• Teraz utwórz plik .gitignore (nawet jeśli jest pusty).
• Zatwierdź plik .gitignore.

Git sprawia, że ​​naprawdę trudno to zrobić, git resetjeśli nie masz żadnych zobowiązań. Jeśli utworzysz małe początkowe zatwierdzenie tylko ze względu na jego posiadanie, potem możesz git add -Aigit reset tyle razy, ile chcesz, aby dostać wszystko prawo.

Kolejną zaletą tej metody jest to, że jeśli później wystąpią problemy z zakończeniem linii i konieczne będzie odświeżenie wszystkich plików, to proste:

• Sprawdź to wstępne zatwierdzenie. Spowoduje to usunięcie wszystkich plików.
• Następnie sprawdź ponownie swoje ostatnie zatwierdzenie. Spowoduje to pobranie świeżych kopii plików przy użyciu bieżących ustawień zakończenia linii.

Może Git ewoluował, odkąd opublikowałeś swoje pytanie.

$> git --version
git version 1.6.2.1

Teraz możesz spróbować:

git reset HEAD .

To powinno być to, czego szukasz.

Pamiętaj, że jeśli nie określisz wersji, musisz dołączyć separator. Przykład z mojej konsoli:

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 wersja 1.7.5.4)

Aby usunąć nowe pliki z obszaru przejściowego (i tylko w przypadku nowego pliku), jak sugerowano powyżej:

git rm --cached FILE

Użyj rm --cached tylko dla nowych plików przypadkowo dodanych.

Aby zresetować każdy plik w określonym folderze (i jego podfolderach), możesz użyć następującego polecenia:

git reset *

Użyj *polecenia do obsługi wielu plików jednocześnie:

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

itp.

Po prostu wpisz git reset, cofnie się z powrotem i jest tak, jakbyś nigdy nie pisał git add .od ostatniego zatwierdzenia. Upewnij się, że dokonałeś wcześniej.

Załóżmy, że utworzę nowy plik newFile.txt:

Załóżmy, że dodam plik przypadkowo git add newFile.txt:

Teraz chcę cofnąć to dodanie przed zatwierdzeniem git reset newFile.txt:

W przypadku konkretnego pliku:

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

Dla wszystkich dodanych plików:

• git reset.
• Git Checkout.

Uwaga: kasa zmienia kod w plikach i przechodzi do ostatniego zaktualizowanego (zatwierdzonego) stanu. reset nie zmienia kodów; po prostu resetuje nagłówek.

Ta komenda usunie twoje zmiany:

git reset HEAD filename.txt

Możesz także użyć

git add -p 

aby dodać części plików.

Istnieje również tryb interaktywny:

git add -i

Wybierz opcję 3, aby usunąć pliki. W moim przypadku często chcę dodać więcej niż jeden plik, a w trybie interaktywnym możesz używać takich liczb do dodawania plików. To zajmie wszystko oprócz 4: 1, 2, 3 i 5

Aby wybrać sekwencję, po prostu wpisz 1-5, aby wziąć wszystkie od 1 do 5.

Pliki pomostowe Git

Aby cofnąć git add, użyj:

git reset filename

git reset filename.txt

Usunie plik o nazwie filename.txt z bieżącego indeksu, obszaru „wkrótce do zatwierdzenia”, bez zmiany czegokolwiek innego.

git add myfile.txt # Spowoduje to dodanie pliku do listy do zatwierdzenia

Wręcz przeciwnie do tego polecenia,

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

więc będziesz w poprzednim stanie. Określony będzie ponownie na liście bez śledzenia (poprzedni stan).

Zresetuje twoją głowę tym określonym plikiem. więc jeśli twoja głowa tego nie ma, po prostu ją zresetuje.

W Sourcetree możesz to łatwo zrobić za pomocą GUI. Możesz sprawdzić, którego polecenia Sourcetree używa do rozpakowywania pliku.

Utworzyłem nowy plik i dodałem go do Git. Następnie odsłoniłem go za pomocą GUI Sourcetree. Oto wynik:

Niestacjonarne pliki [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 używa resetdo wypuszczania nowych plików.

git reset filename.txt  

Usunie plik o nazwie filename.txt z bieżącego indeksu, obszaru „wkrótce do zatwierdzenia”, bez zmiany czegokolwiek innego.