35 Pytanie: Jak cofnąć 'git add' przed zatwierdzeniem?

pytanie utworzone w Mon, Jun 10, 2019 12:00 AM

Pomyłkowo dodałem pliki do git za pomocą polecenia:

 
git add myfile.txt

Jeszcze nie uruchomiłem git commit. Czy istnieje sposób na cofnięcie tego, więc te pliki nie zostaną uwzględnione w zatwierdzeniu?

    
8195
  1. Począwszy od Git v1.8.4, wszystkie poniższe odpowiedzi używające HEAD lub head mogą teraz używać @ zamiast HEAD zamiast. Zobacz tę odpowiedź (ostatnia sekcja) , aby dowiedzieć się, dlaczego możesz zrób to.
    2013-07-26 02: 04: 14Z
  2. Zrobiłem mały podsumowanie, które pokazuje wszystkie sposoby, aby odblokować plik: stackoverflow.com/questions/6919121/…
    2014-04-26 12: 09: 03Z
  3. Dlaczego nie git checkout?
    2016-09-05 14: 57: 00Z
  4. @ ErikReppen git checkout nie usuwa zmian wprowadzonych z indeksu zatwierdzenia. Powoduje jedynie przywrócenie niezmienionych zmian do ostatniej zatwierdzonej wersji - co zresztą też nie jest tym, czego chcę, chcę tych zmian, chcę je po prostu zatwierdzić później.
    2016-09-06 21: 08: 58Z
  5. Jeśli używasz Eclipse, jest to tak proste, jak odznaczenie plików w oknie dialogowym zatwierdzenia
    2016-11-17 12: 49: 17Z
30 odpowiedzi                              30                         

Możesz cofnąć git add przed zatwierdzeniem za pomocą

 
git reset <file>

, który usunie go z bieżącego indeksu (lista „wkrótce zostanie zatwierdzona”) bez zmiany czegokolwiek innego.

Możesz użyć

 
git reset

bez nazwy pliku, aby usunąć wszystkie zmiany. Może się to przydać, gdy w rozsądnym czasie jest zbyt wiele plików, które mają być wymienione jeden po drugim.

W starych wersjach Gita powyższe polecenia są odpowiednikami odpowiednio git reset HEAD <file> i git reset HEAD i nie powiedzie się, jeśli HEAD jest niezdefiniowane (ponieważ nie dokonałeś jeszcze żadnych zatwierdzeń w repo) lub niejednoznaczne (ponieważ utworzyłeś gałąź o nazwie HEAD, co jest głupią rzeczą, której nie powinieneś robić). To zostało zmienione w Git 1.8. 2 , więc w nowoczesnych wersjach Gita możesz używać powyższych poleceń nawet przed pierwszym zatwierdzeniem:

  

„git reset” (bez opcji lub parametrów) używany do błędu, kiedy      nie masz żadnych zobowiązań w swojej historii, ale teraz daje ci to      pusty indeks (aby dopasować nieistniejące zatwierdzenie, nie jesteś nawet włączony).

    
9303
2015-10-29 23: 04: 30Z
  1. Oczywiście nie jest to prawdziwe cofnięcie, ponieważ jeśli niewłaściwy git add nadpisał poprzednią wystawioną niezatwierdzoną wersję, nie możemy go odzyskać. Próbowałem to wyjaśnić w mojej odpowiedzi poniżej.
    2013-05-06 19: 10: 43Z
  2. git reset HEAD *.ext, gdzie ext to pliki danego rozszerzenia, które chcesz usunąć. Dla mnie było to *.bmp i *.zip
    2013-11-26 14: 25: 19Z
  3. @ Jonny, indeks (zwany także obszarem przemieszczania) zawiera wszystkie pliki, a nie tylko zmienione pliki. „Rozpoczyna życie” (kiedy sprawdzasz zatwierdzenie lub klonujesz repo) jako kopię wszystkich plików w zatwierdzeniu wskazanym przez HEAD. Więc jeśli usuniesz plik z indeksu (git rm --cached), to znaczy, że jesteśprzygotowanie do zatwierdzenia, które usuwa ten plik. Z drugiej strony git reset HEAD <filename> skopiuje plik z HEAD do indeksu, tak że następny commit nie pokaże żadnych zmian dokonanych w tym pliku.
    2016-03-16 12: 27: 34Z
  4. Właśnie odkryłem, że istnieje git reset -p, podobnie jak git add -p. To jest niesamowite!
    2016-07-17 23: 23: 05Z
  5. Właściwie możesz odzyskać nadpisane wcześniej zaplanowane, ale niezatwierdzone zmiany , ale nie w sposób przyjazny dla użytkownika i nie w 100% bezpieczny (przynajmniej nie znalazłem żadnego ): goto .git /objects, wyszukaj pliki utworzone w czasie git add, które chcesz odzyskać (61/3AF3... - > identyfikator obiektu 613AF3...), następnie git cat-file -p <object-id> (może być warte odzyskania kilku godzin pracy, ale także lekcja do zatwierdzenia) częściej ...)
    2017-07-31 14: 03: 25Z

Chcesz:

 
git rm --cached <added_file_to_undo>

Rozumowanie:

Kiedy byłem nowicjuszem, po raz pierwszy próbowałem

 
git reset .

(aby cofnąć cały mój początkowy dodatek), tylko po to, aby otrzymać (nie tak) pomocny komunikat:

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

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

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

    ... wiele zwojów crap przez ...

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

  5. google „cofnij git dodaj”

    = > znajdź Przepełnienie stosu - yay

  6. git reset .

    = > fatal: Nie udało się rozwiązać „HEAD” jako prawidłowego ref.

Dalej okazuje się, że jest błąd zalogowany przeciwko nieprzydatność tego na liście mailingowej.

I że poprawne rozwiązanie znajdowało się właśnie w wyjściu stanu Git (które, tak, przejrzałem jako „crap”

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

I rzeczywiście rozwiązaniem jest użycie git rm --cached FILE.

Zwróć uwagę na ostrzeżenia w innych miejscach - git rm usuwa lokalną kopię roboczą pliku, ale nie , jeśli używasz --cached . Oto wynik git help rm:

  

- w pamięci podręcznej       Użyj tej opcji, aby odszyfrować i usunąć ścieżki tylko z indeksu.       Pliki drzewa roboczego, bez względu na to, czy zostały zmodyfikowane, czy nie, zostaną pozostawione.

Kontynuuję używanie

 
git rm --cached .

, aby usunąć wszystko i zacząć od nowa. Nie zadziałało, ponieważ add . jest rekurencyjne, ale rm potrzebuje -r do powtórzenia. Westchnij.

 
git rm -r --cached .

Dobra, teraz wróciłem do miejsca, w którym zacząłem. Następnym razem użyję -n, aby wykonać próbę suchą i zobaczyć, co zostanie dodane:

 
git add -n .

Zapakowałem wszystko w bezpieczne miejsce, zanim zaufałem git help rm, że --cached niczego nie zniszczył (a co jeśli źle to napisałem).

    
2062
2018-09-13 00: 05: 11Z
  1. Hah. Podążyłem za tym samym procesem. Z wyjątkiem tego, że zrezygnowałem i powiedziałem rm -rf .git, git init, ponieważ nie ufałem git rm --cached zachowaniu mojej kopii roboczej. Mówi trochę o tym, jak git jest wciąż zbyt skomplikowany w niektórych miejscach. git unstage powinno być zwykłym standardowym poleceniem, nie obchodzi mnie, czy mogę dodać go jako alias.
    2011-03-29 03: 45: 18Z
  2. Dla mnie git mówi git reset HEAD <File>...
    2012-09-12 06: 50: 13Z
  3. git rm --cached < file > jest właściwie poprawną odpowiedzią, jeśli jest to początkowy import pliku < file > do repozytorium. Jeśli próbujesz odblokować zmianę pliku, poprawną odpowiedzią jest reset git. Ludzie mówiący, że ta odpowiedź jest błędna, myślą o innym pytaniu.
    2013-02-28 22: 14: 57Z
  4. To zadziała, ale tylko przy pierwszym zatwierdzeniu, gdzie plik nie istniał wcześniej lub w którym dodano polecenie git add pliki, ale nie zmiany w istniejących plikach.
    2013-04-10 02: 33: 36Z
  5. po prostu pokazuje, jak mało intuicyjny i zawiły jest git. zamiast równoległych poleceń „cofnij”, musisz dowiedzieć się, jak je cofnąć. Jak próba uwolnienia nogi w szybkim piasku, a następnie zablokowanie ręki, a następnie zablokowanie drugiej ręki ... każde polecenie powinno być wykonane za pomocą interfejsu GUI, z rozwijanymi menu dla opcji ... Pomyśl o całym interfejsie użytkownika, zyski wydajności, które mieliśmy, ale mamy ten bałagan w retro interfejsie linii poleceń. Nie jest tak, że programy GUI git czynią to bardziej intuicyjnym.
    2014-05-24 10: 54: 36Z

Jeśli wpiszesz:

 
git status

git powie ci, co jest inscenizowane, itp., w tym instrukcje, jak odstartować:

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

Uważam, że git wykonuje całkiem niezłą robotę, popychając mnie do robienia właściwych rzeczy w takich sytuacjach.

Uwaga: Ostatnie wersje git (1.8.4.x) zmieniły tę wiadomość:

 
(use "git rm --cached <file>..." to unstage)
    
507
2013-11-09 03: 48: 01Z
  1. Wiadomość będzie inna w zależności od tego, czy add ed plik był już śledzony (add zapisał tylko nową wersję w pamięci podręcznej - tutaj pokaże wiadomość) . Gdzie indziej, jeśli plik nie był wcześniej wystawiony, wyświetli się use "git rm --cached <file>..." to unstage
    2013-05-06 18: 25: 26Z
  2. Świetnie! git reset HEAD <file> jest jedynym, który będzie działał na wypadek, gdybyś chciał zdemontować usunięcie pliku
    2018-02-24 00: 25: 25Z
  3. Moja wersja git 2.14.3 mówi, że git reset HEAD jest niestabilny.
    2018-04-23 19: 16: 53Z

Aby wyjaśnić: git add przenosi zmiany z bieżącego katalogu roboczego do obszaru przemieszczania (indeks).

Ten proces nosi nazwę przemieszczania . Najbardziej naturalną komendą do etapu zmian (zmienionych plików) jest oczywista:

 
git stage

git add jest łatwiejszy do wpisania aliasu dla git stage

Szkoda, że ​​nie ma git unstage ani git unadd poleceń. Odpowiedni jest trudniejszy do odgadnięcia lub zapamiętania, ale jest całkiem oczywiste:

 
git reset HEAD --

Możemy łatwo utworzyć alias do tego:

 
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 nawet krótszych aliasów:

 
git a #for staging
git u #for unstaging
    
240
2013-04-29 13: 05: 17Z
  1. "moves"? Oznaczałoby to, że zniknął z katalogu roboczego. Tak nie jest.
    2017-06-08 09: 18: 33Z
  2. Dlaczego jest to oczywiste?
    2017-06-23 18: 25: 52Z
  3. Właściwie git stage to alias dla git add, który jest historycznym poleceniem zarówno w Git, jak iw innym SCM. Zostało dodane w grudniu 2008 r. Za pomocą commit 11920d28da w „repozytorium git Git”, jeśli mogę powiedzieć.
    2018-09-12 18: 13: 20Z

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ę on zajmować miejsce w katalogu .git. 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 (poprzez klonowanie, wypychanie), a przestrzeń zostanie ostatecznie odzyskanaimed - choć może niedługo. Jeśli jesteś niespokojny, możesz uruchomić:

 
git gc --prune=now

Aktualizacja (to, co następuje, to moja próba wyjaśnienia pewnych nieporozumień, które mogą wynikać z odpowiedzi najczęściej przegłosowanych):

Więc, co to jest prawdziwe cofnięcie 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 cofnąć - ogólnie rzecz biorąc bezpiecznie.

Przypomnijmy sobie najpierw, co faktycznie robi git add <file>:

  1. Jeśli <file> nie zostało wcześniej śledzone , git add dodaje go do pamięci podręcznej z jego aktualną treścią.

  2. Jeśli <file> był już śledzony , git add zapisuje bieżącą zawartość (migawka, wersja) w pamięci podręcznej. W GIT ta akcja jest nadal nazywana dodaj (nie tylko aktualizacją ), ponieważ dwie różne wersje (migawki) pliku są traktowane jako dwa różne elementy: stąd rzeczywiście dodajemy nowy element do pamięci podręcznej, który ostatecznie zostanie zatwierdzony później.

W związku z tym pytanie jest nieco dwuznaczne:

  

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

Scenariusz OP wydaje się być pierwszym (nieśledzony plik), chcemy „cofnąć”, aby usunąć plik (nie tylko bieżącą zawartość) ze śledzonych elementów. Jeśli tak jest, możesz uruchomić git rm --cached <file>.

Możemy również uruchomić git reset HEAD <file>. Jest to ogólnie 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 HEAD nie działa, ale git rm --cached to: nowe repozytorium (bez zatwierdzeń). Ale tak naprawdę to praktycznie nieistotna sprawa.

Po drugie: pamiętaj, że git reset HEAD nie może w magiczny sposób odzyskać poprzednio buforowanej zawartości pliku, po prostu resynchronizuje ją z HEAD. Jeśli nasz błędny git add nadpisał poprzednią wystawioną niezatwierdzoną wersję, nie możemy go odzyskać. 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 lost irrevocably "version 2"
-version 1
+version 3

Oczywiście nie ma to większego znaczenia, jeśli po prostu wykonujemy zwykły, leniwy przepływ pracy polegający na wykonaniu „git add” tylko w celu dodania nowych plików (przypadek 1), a my aktualizujemy nową zawartość za pomocą polecenia commit, git commit -a.


* (Edytuj: powyższe jest praktycznie poprawne, ale wciąż mogą istnieć pewne nieco hackerskie /zawiłe sposoby odzyskiwania zmian, które zostały wprowadzone, ale nie zatwierdzone, a następnie nadpisane - zobacz komentarze Johannesa Matokica i iolsmit)

    
161
2018-10-15 17: 23: 57Z
  1. Ściśle mówiąc, istnieje sposób na odzyskanie już zaimportowanego pliku, który został zastąpiony przez git add. Jak wspomniałeś, git add tworzy obiekt git dla tego pliku, który stanie się luźnym obiektem nie tylko podczas całkowitego usuwania pliku, ale także podczas zastępowania go nową zawartością. Ale nie ma polecenia, aby automatycznie je odzyskać. Zamiast tego plik musi zostać zidentyfikowany i wyodrębniony ręcznie lub za pomocą narzędzi napisanych tylko dla tego przypadku (libgit2 na to pozwoli). Ale to zapłaci tylko wtedy, gdy plik jest bardzo ważny i duży i nie można go odbudować przez edycję poprzedniej wersji.
    2017-12-06 13: 07: 37Z
  2. Aby poprawić siebie: Po znalezieniu luźnego pliku obiektu (użyj meta-danych, takich jak data /czas utworzenia) git cat-file może zostać użyty do odzyskania jego zawartości.
    2017-12-06 13: 22: 17Z
  3. Inny sposób na odzyskanie zmian, które zostały wprowadzone, ale nie zatwierdzone, a następnie nadpisane przez np. innym git add jest via git fsck --unreachable, który wyświetli wszystkie nieosiągalne obiekty, które można następnie sprawdzić za pomocą git show SHA-1_ID lub git fsck --lost-found, które będą zapisywać zwisające obiekty w .git/lost-found/commit/ lub .git/lost-found/other/, w zależności od typu. Zobacz także git fsck --help
    2018-04-27 15: 29: 46Z
 
git rm --cached . -r

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

    
92
2013-05-28 15: 18: 28Z
  1. Nie chciałem usuwać wszystkiego, tylko JEDEN określony plik.
    2009-12-09 22: 35: 27Z
  2. Pomocny również, jeśli nie masz żadnych poprzednich zatwierdzeń. W przypadku braku wcześniejszego zatwierdzenia git reset HEAD <file> powiedziałoby fatal: Failed to resolve 'HEAD' as a valid ref.
    2013-06-02 03: 46: 13Z
  3. Nie, to dodaje usunięcie wszystkiego w bieżącym katalogu. Bardzo różni się od zwykłych zmian.
    2015-10-30 01: 33: 56Z

Uruchom

 
git gui

i usuń wszystkie pliki ręcznie lub zaznacz wszystkie i kliknij przycisk Unstage from commit .

    
85
2013-03-09 11: 21: 19Z
  1. Tak, rozumiem to. Chciałem tylko sugerować, że twoja odpowiedź wskazuje na „Możesz użyć git-gui ....” :)
    2014-08-01 16: 11: 05Z
  2. Mówi "git-gui: command not found". Nie jestem pewien, czy to działa.
    2017-09-13 04: 19: 18Z
  3. Wow, to jest bardzo proste, a następnie wykonywanie linii poleceń, których nie rozumiesz. Jest to zdecydowanie zalecane dla początkujących, takich jak ja. Dziękujemy za napisanie tego!
    2019-04-11 04: 27: 43Z

Cofnij plik, który już został dodany, jest dość łatwy przy użyciu git , aby zresetować myfile.txt, które już dodano, użyj:

 
git reset HEAD myfile.txt

Wyjaśnij :

Po umieszczeniu niechcianych plików, aby cofnąć, można wykonać git reset, Head jest głową pliku w lokalnym, a ostatnim parametrem jest nazwa pliku.

Tworzę kroki na obrazku poniżej, bardziej szczegółowo, łącznie ze wszystkimi krokami, które mogą się zdarzyć w następujących przypadkach:

 plik HEAD resetowania git

    
85
2019-03-21 09: 34: 42Z
  1. AMAZING !!!!!!!!!!!!!!!!!!!!!
    2019-03-26 12: 56: 08Z

Git ma komendy dla każdej możliwej akcji, ale potrzebuje obszernej wiedzy, aby wszystko było w porządku i dlatego jest w najlepszym razie sprzeczne z intuicją ...

Co zrobiłeś wcześniej:

  • Zmieniono plik i użyto git add . lub git add <file>.

Co chcesz:

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

     
    git reset head <file>
    
  • Zresetuj plik do ostatniego stanu z 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 HEAD nie będzie działać z pojedynczymi plikami.

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

     
    git rm --cached <file>
    
  • Całkowicie usuń <file> z kopii roboczej i wersjonowania:

     
    git rm <file>
    
80
2015-10-30 01: 37: 07Z
  1. Nie mogę znieść różnicy między 'git reset head < file >' i 'git rm --cached < file &gt ;. Mógłbyśwyjaśnij to?
    2013-08-14 00: 39: 07Z
  2. Pliki @ jeswang są albo znane „git” (zmiany w nich są śledzone.), albo nie są „wersjonowane”. reset head cofa bieżące zmiany, ale plik jest nadal monitorowany przez git. rm --cached usuwa plik z wersji, więc git nie sprawdza go już pod kątem zmian (a także usuwa zindeksowane zmiany obecne, powiedziane na git przez poprzednią add), ale zmieniony plik będzie przechowywany w kopii roboczej, czyli w tobie folder plików na dysku twardym.
    2013-08-15 15: 09: 40Z
  3. Różnica wynosi git reset HEAD <file> jest tymczasowa - komenda zostanie zastosowana tylko do następnego zatwierdzenia, ale git rm --cached <file> będzie się wycofywać, dopóki nie zostanie ponownie dodane z git add <file>. Ponadto git rm --cached <file> oznacza, że ​​jeśli pchniesz tę gałąź do pilota, każdy, kto pociągnie ją za gałąź, otrzyma plik ACTUALLY usunięty z ich folderu.
    2014-08-10 19: 54: 43Z

Pytanie nie jest wyraźnie postawione. Powodem jest to, że git add ma dwa znaczenia:

  1. dodanie nowego pliku do obszaru przemieszczania, a następnie cofnięcie za pomocą git rm --cached file.
  2. dodanie pliku zmodyfikowanego do obszaru przemieszczania, a następnie cofnięcie za pomocą git reset HEAD file.

w razie wątpliwości użyj

 
git reset HEAD file

Ponieważ w obu przypadkach działa w oczekiwany sposób.

Ostrzeżenie: jeśli zrobisz git rm --cached file na pliku zmodyfikowanym (plik, który istniał wcześniej w repozytorium), plik zostanie usunięty na git commit! Nadal będzie istnieć w twoim systemie plików, ale jeśli ktoś inny podejmie twoje zatwierdzenie, plik zostanie usunięty z drzewa roboczego.

git status powie Ci, czy plik był nowym plikiem lub zmodyfikowanym :

 
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
    
73
2015-10-30 23: 47: 29Z
  1. + 1. Niezwykła liczba wysoko ocenionych odpowiedzi i komentarzy na tej stronie jest po prostu błędna w kwestii zachowania git rm --cached somefile. Mam nadzieję, że ta odpowiedź trafi na stronę w widocznym miejscu, gdzie może chronić nowicjuszy przed wprowadzeniem w błąd przez wszystkie fałszywe roszczenia.
    2015-10-30 23: 44: 32Z
  2. jedna z najlepszych odpowiedzi tutaj, niestety jest dość niska na liście
    2019-06-10 01: 10: 36Z

Jeśli jesteś na początkowym zatwierdzeniu i nie możesz użyć git reset, po prostu zadeklaruj „Git bankruptcy” i usuń folder .git i zacznij od nowa

    
62
2019-02-17 12: 01: 36Z
  1. Jedna wskazówka polega na skopiowaniu pliku .git /config, jeśli dodano zdalne źródło, przed usunięciem folderu.
    2010-03-08 23: 15: 52Z
  2. Komentarz @ ChrisJohnsena jest na miejscu. Czasami chcesz zatwierdzić wszystkie pliki z wyjątkiem jednego: git add -A && git rm --cached EXCLUDEFILE && git commit -m 'awesome commit' (działa to również wtedy, gdy nie ma poprzednich zatwierdzeń, ponownie problem Failed to resolve 'HEAD')
    2013-03-29 04: 20: 41Z

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

BUT:

Znalazłem ten świetny mały post, który faktycznie dodaje polecenie Git (dobrze alias) dla git unadd: zobacz git unadd po szczegóły lub ..

Po prostu

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

Teraz możesz

 
git unadd foo.txt bar.txt
    
55
2016-07-13 16: 51: 08Z
W tym celu można użyć

git remove lub git rm z flagą --cached. Spróbuj:

 
git help rm
    
45
2013-03-09 11: 14: 55Z
  1. Czy to nie spowoduje całkowitego usunięcia pliku?
    2015-08-26 05: 29: 10Z
  2. git rm --cached ... usunie pliki z repozytorium git. Będą one nadal istniały na twoim komputerze, ale to BARDZO różni się od niestacjonarnych zmian do pliku. Dla każdego, kto się na to natknie, nie jest to prawidłowa odpowiedź na pytanie.
    2018-12-17 20: 02: 59Z

Użyj git add -i, aby usunąć tylko dodane pliki z nadchodzącego zatwierdzenia. Przykład:

Dodawanie pliku, którego nie chcesz:

 
$ 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 dodania (polecenia wpisywane w git tutaj to „r” (revert), „1” (pierwszy wpis na liście pokazuje zmiany), „return”, aby zrezygnować z trybu przywracania i „q” (quit):

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

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

 
$ 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)
$
    
42
2012-12-21 22: 14: 31Z

Oto sposób na uniknięcie tego dokuczliwego problemu podczas uruchamiania nowego projektu:

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

Git sprawia, że ​​naprawdę trudno jest zrobić git reset, jeśli nie masz żadnych zatwierdzeń. Jeśli utworzysz małe początkowe zatwierdzenie tylko ze względu na posiadanie jednego, możesz git add -A i git reset tyle razy, ile chcesz, aby wszystko było w porządku.

Kolejną zaletą tej metody jest to, że jeśli napotkasz problemy z zakończeniem linii później i będziesz musiał odświeżyć wszystkie swoje pliki, jest to łatwe:

  • Sprawdź to wstępne zatwierdzenie. Spowoduje to usunięcie wszystkich plików.
  • Następnie sprawdź ponownie swoje ostatnie zatwierdzenie. Spowoduje to pobranie nowych kopii plików przy użyciu bieżących ustawień zakończenia linii.
37
2012-05-10 18: 59: 01Z
  1. Potwierdzony! Próbowałem zresetować git po dodaniu gita. a git narzekał na skorumpowaną HEAD. Podążając za twoją radą, mógłbym dodać i amp; resetuj bez problemów :)
    2012-10-03 21: 32: 16Z
  2. Druga część działa, ale jest trochę niezdarna. Sposób obsługi końców linii zależy od wartości autocrlf ... To nie zadziała w każdym projekcie, w zależności od ustawień.
    2013-03-29 11: 26: 58Z
  3. Ta odpowiedź była rozsądna w momencie jej opublikowania, ale teraz jest przestarzała; git reset somefile i git reset działają teraz przed pierwszym zatwierdzeniem. Tak było od czasu, gdy kilka Git zwalnia.
    2015-10-30 23: 38: 32Z
  4. @ MarkAmery, możesz mieć rację (fajnie by było, gdybyś umieścił źródło dla twojego potwierdzenia), ale nadal jest wartość w rozpoczęciu repo z czystym zatwierdzeniem lub dwa.
    2015-10-31 20: 01: 14Z

Może Git ewoluował od czasu wysłania pytania.

 
$> git --version
git version 1.6.2.1

Teraz możesz spróbować:

 
git reset HEAD .

To powinno być to, czego szukasz.

    
33
2013-03-09 11: 17: 13Z
  1. Pewnie, ale potem masz pytanie, jak należy dodać jeden z dwóch (lub więcej) dodanych plików. Podręcznik „git reset” wspomina, że ​​„git reset < paths >” jest jednak przeciwieństwem „git add < paths >”.
    2013-05-15 13: 36: 21Z

Zauważ, ż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>

(wersja git 1.7.5.4)

    
33
2014-04-05 05: 32: 50Z
  1. Próbowałem git reset <path> i działa dobrze bez separatora. Używam także git 1.9.0. Może nie działa w starszych wersjach?
    2014-04-05 05: 32: 25Z

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

 
git rm --cached FILE

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

    
30
2009-06-22 19: 46: 28Z
  1. Pamiętaj, że --cached jest naprawdę ważną częścią.
    2013-04-12 12: 21: 46Z
  2. - 1; nie, to nie usuwa pliku, powoduje usunięcie pliku (bez usuwania go z drzewa roboczego).
    2015-10-30 23: 42: 05Z

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

 
git reset *
    
24
2012-07-26 07: 50: 36Z
  1. Właściwie to nie resetuje każdego pliku, ponieważ * używa rozszerzenia powłoki i ignoruje pliki dotfile (i katalogi kropkowe).
    2014-05-04 23: 20: 01Z
  2. Możesz uruchomić git status, aby zobaczyć cokolwiek pozostałego i zresetować go ręcznie, tj. git reset file.
    2014-05-07 15: 23: 55Z

użyj polecenia * do obsługi wielu plików naraz

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

etc

    
24
2013-08-27 21: 15: 05Z
  1. Pamiętaj, że * zwykle nie zawiera plików dotfiles lub „dot-directories”, chyba że wyraźnie określisz .* lub .*.prj
    2014-05-04 23: 21: 06Z

Wystarczy wpisać git reset, aby powrócić i to było tak, jakbyś nigdy nie wpisał git add . od ostatniego zatwierdzenia. Upewnij się, że popełniłeś wcześniej.

    
22
2015-04-22 10: 57: 19Z
    Nie działa, jeśli nie ma ostatniego zatwierdzenia.
    2012-04-11 22: 07: 03Z
  1. Jak się zdarzyło, to było ostatnie zatwierdzenie ... ale specjalnie pytałem o usunięcie pojedynczego pliku z zatwierdzenia, a nie każdego pliku z zatwierdzenia.
    2013-01-31 16: 21: 37Z

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

 wprowadź opis obrazu tutaj>> </a> </p>

<p> Załóżmy, że przypadkowo dodam plik, <code>git add newFile.txt</code> </p>

<p> <a href= wprowadź opis obrazu tutaj>> </a> </p>

<p> Teraz chcę cofnąć to dodanie, przed zatwierdzeniem, <code>git reset newFile.txt</code> </p>

<p> <a href= wprowadź opis obrazu tutaj>> </a> </p>
    </div>
<div class = 18

2016-10-04 11: 02: 48Z
  1. Przypuśćmy, że jestem na pierwszym zdjęciu, co oznacza, że ​​nawet nie zrobiłem "git.add". Poza tym wcale nie chcę całej tej zmiany. To znaczy, gdy robię status git, nie powinien on wyświetlać żadnych czerwonych plików. To znaczy, że powinien być zsynchronizowany tak, jakby nie było zmienionego pojedynczego pliku od czasu ostatniego git push. jak to osiągnąć.
    2017-03-26 00: 59: 40Z
  2. SO załóżmy, że jesteś na początku. I chcesz pozbyć się wszystkich zmian, które zrobiłeś, dzięki czemu „newFile.txt” stanie się czerwony.
    2017-03-26 01: 00: 12Z
  3. Kiedy robię status git. Nie powinienem widzieć żadnych zmian. Wszystkie czerwone pliki powinny zostać przywrócone.
    2017-03-26 01: 00: 50Z
  4. Cześć, myślę, że twoje pytanie brzmi, jak usunąć nieśledzone pliki z bieżącego drzewa. W tym celu możesz użyć „git clean -f -d”. Spowoduje to również usunięcie nieśledzonych katalogów.
    2017-03-26 10: 19: 04Z
  5. Jeśli nie chcesz usuwać nieśledzonych plików, po prostu zignoruj ​​flagę "-f".
    2017-03-26 10: 20: 26Z

Dla konkretnego pliku:

  
  • git resetuje mój_plik.txt
  •   
  • git checkout my_file.txt
  •   

Dla wszystkich dodanych plików:

  
  • reset git.
  •   
  • git checkout.
  •   

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

    
17
2018-09-28 18: 11: 49Z
  1. Proszę wyjaśnić różnicę między git reset <file> a git checkout <file>.
    2018-01-22 23: 47: 24Z
  2. reset nie zmienia pliku, po prostu odłóż go ze sceny (= indeks, gdzie został umieszczony przez git add)
    2018-03-12 11: 18: 32Z
  3. checkout zmień kody w pliku i przejdź do ostatniego zaktualizowanego stanu. reset nie zmienia kodów po prostu resetuje nagłówek. Jako przykład, zresetuj użycie dodanych lub zatwierdzonych plików resetowanie przed użyciem push i checkout z powrotem do ostatniego zaktualizowanego /zatwierdzonego etapu przed dodaniem git.
    2018-03-14 11: 38: 53Z
  4. reset = usuń plik ze sceny, ale zmiany będą nadal występować. checkout = pobiera zaktualizowany plik z repozytorium i nadpisuje bieżący plik
    2018-09-12 10: 16: 22Z

To polecenie rozwiąże twoje zmiany:

 
git reset HEAD filename.txt

Możesz także użyć

 
git add -p 

, aby dodać części plików.

    
13
2013-03-09 11: 22: 31Z

Jestem zaskoczony, że nikt nie wspomina trybu interaktywnego:

 
git add -i

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

Aby wybrać sekwencję, wpisz 1-5, aby zabrać wszystkie od 1 do 5.

Pliki przemieszczania Git

    
13
2015-10-26 12: 20: 07Z
  1. "Jestem zaskoczony, że nikt nie wspomina trybu interaktywnego" - zrobili to: stackoverflow.com/a/10209776/1709587
    2015-10-30 23: 52: 13Z

Aby cofnąć użycie git add

git reset filename

    
13
2016-10-02 15: 54: 48Z
 
git reset filename.txt

Usunie plik o nazwie nazwapliku.txt z bieżącego indeksu, „obszar, który ma zostać zatwierdzony”, bez zmiany niczego innego.

    
9
2016-07-11 18: 40: 52Z

git add myfile.txt # spowoduje dodanie twojego pliku do listy zatwierdzonych

W przeciwieństwie 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 nieśledzonej (poprzedni stan).

zresetuje twoją głowę za pomocą określonego pliku. więc jeśli twoja głowa nie ma takiego znaczenia, po prostu ją zresetuje

    
9
2017-06-27 13: 58: 34Z

W SourceTree możesz to łatwo zrobić za pomocą gui. Możesz sprawdzić, które polecenie używa źródła, aby rozpakować plik.

Stworzyłem nowy plik i dodałem go do git. Następnie rozłożyłem go za pomocą GUI SourceTree. Oto rezultat:

  

Pliki bez przestojów [12.12.2015 10:43]
  git -c diff.mnemonicprefix = false -c core.quotepath = false -c credential.helper = reset kwaśnego źródła -q - ścieżka /do /file /filename.java

SourceTree używa reset do rozpakowywania nowych plików.

    
8
2015-12-08 09: 58: 33Z

Jednym z najbardziej intuicyjnych rozwiązań jest SourceTree .

Możesz po prostu przeciągać i upuszczać pliki z etapów i bez scen „wprowadź

    
7
2017-05-26 08: 32: 16Z
źródło umieszczone tutaj