Jak cofnąć 'git add' przed zatwierdzeniem?

Chcesz:

git rm --cached <added_file_to_undo>

Rozumowanie:

git reset .

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

Okazuje się, że dzieje się tak dlatego, że główny ref (gałąź?) istnieje dopiero po pierwszym commicie. Oznacza to, że napotkasz ten sam problem początkującego, co ja, jeśli twój przepływ pracy, taki jak mój, był czymś w stylu: {]}

1. cd do mojego nowego katalogu projektów, aby wypróbować Git, new hotness
2. git init
3. git add .

4. git status

   ... mnóstwo gównianych zwojów ...

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

5. Google "undo git add"

   = > find Stack Overflow - yay

6. git reset .

   = > fatal: nie udało się rozwiązać "głowy" jako ważnego ref.

Dalej okazuje się, że jest błąd zalogowany przeciwko nieprzydatności tego w Lista mailingowa.

And that the correct solution was right there in the Git status output (which, yes, I glossed over as ' shit)

...
# 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 innym miejscu - git rm usuwa lokalną kopię roboczą pliku, ale Nie jeśli używasz -- cached . Oto wynik git help rm:

-- cached Użyj tej opcji, aby usunąć ścieżki tylko z indeksu. Pliki robocze drzewa, czy zmodyfikowane, czy nie, zostaną pozostawione.

Przystępuję do używania

git rm --cached .

Aby usunąć wszystko i zacząć od nowa. Jednak nie zadziałało, ponieważ o ile add . jest rekurencyjne, to okazuje się, że rm potrzebuje -r do rekurencji. Westchnienie.

git rm -r --cached .

git add -n .

Spakowałem wszystko w bezpieczne miejsce, zanim zaufałem git help rm o --cached nie niszcząc niczego (a co jeśli źle to napisałem).

Jeśli wpiszesz:

git status

Git powie Ci co jest wystawione, itp., wraz z instrukcją jak usunąć:

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

Uważam, że Git robi całkiem dobrą robotę, nakłaniając mnie do zrobienia właściwej rzeczy w takich sytuacjach.

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

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

Dla wyjaśnienia: git add przenosi zmiany z bieżącego katalogu roboczego do strefy postojowej (indeks).

Ten proces nazywa się staging . Tak więc najbardziej naturalne polecenie stage the changes (zmienione pliki) Jest oczywiste:

git stage

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

Szkoda, że nie ma git unstage ani git unadd poleceń. To, co istotne, jest trudniejsze do odgadnięcia lub zapamiętania, ale jest dość oczywiste: {]}

git reset HEAD --

Możemy łatwo utworzyć dla tego aliasu:

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

I wreszcie mamy nowe komendy:

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 błędnie dodany plik był ogromny, prawdopodobnie zauważysz, że nawet po usunięciu go z indeksu za pomocą ' git reset' nadal wydaje się zajmować miejsce w katalogu .git.

Nie ma się czym martwić; plik rzeczywiście nadal znajduje się w repozytorium, ale tylko jako "luźny obiekt". Nie zostanie skopiowany do innych repozytoriów (poprzez clone, push), a przestrzeń zostanie ostatecznie odzyskana-choć być może nie wkrótce. Jeśli jesteś niespokojny, możesz biec:

git gc --prune=now

Aktualizacja (poniżej znajduje się moja próba wyjaśnienia nieporozumień, które mogą wyniknąć z najbardziej upvoted odpowiedzi): {]}

Więc, która jest prawdziwa Cofnij Z git add?

git reset HEAD <file> ?

Lub

git rm --cached <file>?

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

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

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

1. If <file> was not previously tracked, git add dodaje go do bufora , wraz z jego bieżącą zawartością.

2. If <file> was already tracked, git add zapisuje bieżącą zawartość (migawka, Wersja) do pamięci podręcznej. W Git, ta akcja jest nadal nazywana add, (nie tylko update it), ponieważ dwie różne wersje (migawki) pliku są traktowane jako dwie różne pozycje. nowa pozycja w pamięci podręcznej, która zostanie później zatwierdzona.

Omyłkowo dodałem pliki używając komendy...

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

I możemy również uruchomić git reset HEAD <file>. To jest w ogólnie lepiej, ponieważ działa w obu scenariuszach: wykonuje również cofanie, gdy błędnie dodaliśmy wersję już śledzonego elementu.

Po pierwsze: istnieje (jak zaznaczono w odpowiedzi) tylko jeden scenariusz, w którym git reset HEAD nie działa, ale git rm --cached Działa: nowe repozytorium (bez zmian). Ale tak naprawdę to praktycznie nieistotna sprawa.

Po drugie: należy pamiętać, że git reset HEAD nie można magicznie odzyskać wcześniej buforowanej zawartości pliku, po prostu resynchronizuje go z głowy. Jeśli nasza błędna git add nadpisała poprzednią wersję, nie możemy jej 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 irrevocably lost "version 2"
-version 1
+version 3

Oczywiście, nie jest to bardzo krytyczne, jeśli po prostu podążamy za zwykłym leniwym przepływem pracy wykonując 'git add' tylko dla dodawania nowych plików (przypadek 1) i aktualizujemy nową zawartość za pomocą polecenia commit, git commit -a.

^{* (Edit: powyższe jest praktycznie poprawne, ale nadal istnieje mogą to być nieco hakerskie / zawiłe sposoby na odzyskanie zmian, które zostały zainscenizowane, ale nie popełnione, a następnie nadpisane-Zobacz komentarze Johannesa Matokicia i jolsmita)}

Undo plik, który został już dodany jest dość łatwy przy użyciu Git. Do resetowania myfile.txt, które zostały już dodane, użyj:

git reset HEAD myfile.txt

Explanation:

Po ustawieniu niechcianych plików, aby cofnąć, możesz zrobić git reset. Head jest nagłówkiem pliku w pliku lokalnym, a ostatnim parametrem jest nazwa pliku.

Stworzyłem kroki na poniższym obrazku, aby bardziej szczegółowo dla Ciebie, w tym wszystkie kroki, które mogą się zdarzyć w tych przypadki:

git rm --cached . -r

Czy" un-add " wszystko, co dodałeś z bieżącego katalogu rekurencyjnie

Run

git gui

I usunąć wszystkie pliki ręcznie lub wybierając je wszystkie i klikając naunstage z przycisku commit .

Git ma komendy dla każdej możliwej do wyobrażenia akcji, ale potrzebuje rozległej wiedzy, aby wszystko było dobrze i dlatego jest w najlepszym razie intuicyjny...

Co zrobiłeś wcześniej:

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

Czego 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 stan z głowy, cofanie zmian i usuwanie ich 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 wersji, zachowując plik bez wersji ze zmianami w kopii roboczej:

   git rm --cached <file>
  

• Usuń <file> z kopii roboczej i całkowicie wersjonowanie:

   git rm <file>
  

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

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

W razie wątpliwości należy użyć

git reset HEAD file

Ponieważ robi to oczekiwane rzeczy w obu przypadkach.

Warning: if you do git rm --cached file on a file that was modified (a file that existed before w repozytorium), wtedy plik zostanie usunięty na git commit! Nadal będzie on istniał w Twoim systemie plików, ale jeśli ktoś inny wyciągnie Twój commit, plik zostanie usunięty z jego 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

Jeśli używasz pierwszego commita i nie możesz użyć git reset, po prostu zadeklaruj "Git bankructwo" i usuń .git folder i zacznij od nowa

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

Ale:

Znalazłem świetny post, który dodaje komendę Git (no, 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

Użyj git add -i, aby usunąć właśnie dodane pliki z nadchodzącego commita. 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, aby cofnąć dodawanie (polecenia wpisane w git tutaj to "r" (revert)," 1 "(pierwszy wpis na liście revert pokazuje), "return", aby opuścić tryb 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.
$

$ 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 remove w tym celu można użyć znacznika git rm. Try:

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.
• Run git init.
• teraz Utwórz .plik gitignore (nawet jeśli jest pusty).
/ Align = "left" / plik gitignore.

Git utrudnia wykonanie git reset jeśli nie masz żadnych commitów. Jeśli tworzysz mały commit początkowy tylko po to, aby go mieć, Możesz git add -A i git reset tyle razy, ile chcesz, aby uzyskać wszystko w porządku.

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

• Sprawdź ten początkowy commit. Spowoduje to usunięcie wszystkich plików.
• następnie sprawdź swój ostatni commit ponownie. Spowoduje to pobranie świeżych kopii plików przy użyciu bieżących ustawień zakończenia linii.

Zauważ, że jeśli nie podasz 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 version 1.7.5.4)

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

$> git --version
git version 1.6.2.1

git reset HEAD .

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

git rm --cached FILE

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

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 naraz:

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

Itd.

Po prostu wpisz git reset to powróci z powrotem i jest tak, jakbyś nigdy nie wpisał git add . od ostatniego commita. Upewnij się, że wcześniej się zobowiązałeś.

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

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

Teraz chcę cofnąć ten add, przed commit, git reset newFile.txt:

Dla konkretnego pliku:

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

Dla wszystkich dodanych plików:

• git reset .
• Git checkout .

Uwaga: checkout zmienia kod w plikach i przechodzi do ostatniego zaktualizowanego (zatwierdzonego) stanu. reset nie zmienia kodów, tylko resetuje nagłówek.

Aby cofnąć git add, Użyj:

git reset filename

Istnieje również tryb interaktywny:

git add -i

Wybierz opcję 3, aby anulować dodawanie plików. W moim przypadku często chcę dodać więcej niż jeden plik, a w trybie interaktywnym można użyć liczb takich jak ten, aby dodać pliki. To zajmie wszystko oprócz 4: 1, 2, 3 i 5

Aby wybrać sekwencję, wystarczy wpisać 1-5, aby wziąć wszystkie od 1 do 5.

Git staging files

To polecenie usunie Twoje zmiany:

git reset HEAD filename.txt

Możesz również użyć

git add -p 

Aby dodać części plików.

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

Przeciwieństwem tego polecenia jest

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

Zresetuje twoją głowę tym określonym plikiem. tak więc, jeśli Twoja głowa nie ma środków, po prostu ją zresetuje.

git reset filename.txt

Usunie plik o nazwie filename.txt z bieżącego indeksu, obszaru "o zobowiązaniu", bez zmiany czegokolwiek innego.

git reset filename.txt  

Usunie plik o nazwie filename.txt z bieżącego indeksu, obszaru "o zobowiązaniu", bez zmiany czegokolwiek innego.

W Sourcetree możesz to łatwo zrobić poprzez GUI. Możesz sprawdzić, które polecenie Sourcetree używa do zatrzymania pliku.

Utworzyłem nowy plik i dodałem go do Gita. Następnie rozpakowałem go za pomocą GUI Sourcetree. Jest to wynik:

[2010-08-12 10: 43]] Git-C diff.mnemonicprefix=false-C core.quotepath=false-chelper = SourceTree reset-q -- path / to / file / filename.java

Sourcetree używa reset do usuwania nowych plików.