Pamiętaj, że w git Masz:

• the HEAD pointer , który informuje, nad jakim commitem pracujesz
• drzewo robocze , które reprezentuje stan plików w systemie
W 2004 roku, po raz pierwszy w historii, w 2006 roku, w Polsce, w 2007 roku, w Polsce, w 2008 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce, w 2009 roku, w Polsce i na świecie.]}

Proszę dołączyć szczegółowe wyjaśnienia dotyczące:

--hard, --soft oraz --merge;

W rosnącej kolejności niebezpieczeństwa:

• --soft porusza się HEAD, ale nie dotyka miejsca postoju ani drzewa roboczego.
• --mixed przenosi HEAD i aktualizuje miejsce postoju, ale nie drzewo robocze.
• --merge przenosi HEAD, resetuje miejsce postoju i próbuje przenieść wszystkie zmiany w roboczym drzewie do nowego drzewa roboczego.
• --hard ruchy HEAD i dostosowuje obszar postoju i drzewo robocze do nowego HEAD, wyrzucam wszystko.

Konkretne przypadki użycia i przepływy pracy;

• Użyj --soft, Gdy chcesz przejść do innego commita i łatać rzeczy bez "utraty swojego miejsca". To rzadkość, że tego potrzebujesz.

--

# git reset --soft example
touch foo                            // Add a file, make some changes.
git add foo                          // 
git commit -m "bad commit message"   // Commit... D'oh, that was a mistake!
git reset --soft HEAD^               // Go back one commit and fix things.
git commit -m "good commit"          // There, now it's right.

--

• Użyj --mixed (która jest domyślna), gdy chcesz zobaczyć, jak wyglądają zmiany w innym commicie, ale nie chcesz stracić już żadnych zmian mam.

• Użyj --merge, Gdy chcesz przenieść się do nowego miejsca, ale włącz zmiany, które już masz, do działającego drzewa.

• Użyj --hard, aby wymazać wszystko i rozpocząć nową listę przy Nowym commicie.

Post Reset Demystified na blogu Pro Git daje bardzo no-brainer Wyjaśnienie na git reset i git checkout.

Po całej pomocnej dyskusji na górze tego postu, autor redukuje Zasady do następujących prostych trzech kroków:

To w zasadzie wszystko. Polecenie reset nadpisuje te trzy drzewa w określonej kolejności, zatrzymując się, gdy je polecisz.

1. przenieść cokolwiek gałąź HEAD wskazuje na (stop if --soft)
2. następnie, aby Indeks wyglądał tak (zatrzymaj tutaj, chyba że --hard)
3. następnie spraw, aby katalog roboczy wyglądał tak

Są też opcje --merge i --keep, ale na razie wolałbym, żeby było prościej - to będzie dla innego artykułu.

Kiedy zatwierdzasz coś do Gita, musisz najpierw dodać do indeksu swoje zmiany. Oznacza to, że musisz dodać wszystkie pliki, które chcesz umieścić w tym zatwierdzeniu, zanim git uzna je za część zatwierdzania. Najpierw przyjrzyjmy się obrazowi repo Gita:

Teraz to proste. Musimy pracować w working directory, tworząc pliki, katalogi i w ogóle. Zmiany te nie są śledzone. Aby były śledzone, musimy dodać je do indeksu git za pomocą git add polecenie. Po dodaniu ich do indeksu git. Możemy teraz zatwierdzić te zmiany, jeśli chcemy je przenieść do repozytorium git.

Ale nagle dowiedzieliśmy się, że mamy jeden dodatkowy plik, który dodaliśmy do indeksu, nie jest wymagany do wciśnięcia w repozytorium git. To znaczy, że nie chcemy tego pliku w indeksie. Teraz pytanie brzmi, jak usunąć ten plik z indeksu git, ponieważ użyliśmy git add aby umieścić go w indeksie, logicznym byłoby użycie git rm? Źle! git RM po prostu usunie plik i doda go do indeksu. Więc co teraz zrobić:

Użycie: -

Git reset

Czyści Twój indeks, pozostawia Twój katalog roboczy nietknięty. (po prostu odinstaluj wszystko).

Może być używany z wieloma opcjami. Istnieją trzy główne opcje do użycia z git reset: --hard, -- soft I --mixed . Wpływają one na to, co get jest reset oprócz wskaźnika głowy, gdy reset.

Po pierwsze, --hard resetuje wszystko. Twój bieżący katalog byłby dokładnie taki, jak gdybyś cały czas śledził tę gałąź. Katalog roboczy i indeks są zmieniane na ten commit. Jest to wersja, której używam najczęściej. git reset --hard jest czymś w rodzaju svn revert .

Następnie, całkowite przeciwieństwo, - soft , nie resetuje drzewa roboczego ani indeksu. Przesuwa tylko wskaźnik głowy. To pozostawia Twój prąd wprowadź zmiany inne niż zmiany, które zmieniasz na miejsce w katalogu i "zainscenizuj" do zatwierdzenia. Jeśli tworzysz commit lokalnie, ale nie wypchnąłeś go na serwer git, możesz zresetować poprzedni commit i ponownie go zatwierdzić.

Wreszcie, --mixed resetuje indeks, ale nie drzewo robocze. Tak więc wszystkie zmiany nadal tam są, ale są "unstaged" i musiałyby być git add lub git commit-a . używamy tego czasami, jeśli popełniliśmy więcej niż zamierzaliśmy za pomocą git commit-a, możemy wycofać commit za pomocą git reset --mixed, dodać rzeczy, które chcemy zatwierdzić i po prostu je zatwierdzić.

różnica między git revert i GIT reset :-

W prostych słowach, git reset jest poleceniem "fix-commited mistakes" i git revert jest poleceniem "fix-commited mistakes".

Oznacza to, że jeśli popełniliśmy jakiś błąd w jakimś change and commited and pushed the same to git repo, then git revert jest rozwiązaniem. A jeśli w przypadku, gdy zidentyfikowaliśmy ten sam błąd przed naciśnięciem / zatwierdzeniem, możemy użyć git reset, aby rozwiązać problem.

Mam nadzieję, że pomoże Ci pozbyć się zamieszania.

TL;DR

git reset resetuje inscenizację do ostatniego zatwierdzenia. Użyj --hard, aby zresetować pliki w katalogu roboczym do ostatniego zatwierdzenia.

DŁUŻSZA WERSJA

Ale to jest oczywiście uproszczone, stąd wiele dość gadatliwych odpowiedzi. Bardziej sensowne było dla mnie przeczytanie git reset w kontekście cofania zmian. Np. ZOBACZ TO:

Jeśli git revert jest "bezpiecznym" sposobem cofania zmian, możesz myśleć o git reset jako niebezpieczna metoda. Gdy cofasz z Git reset (i commity nie są już referowane przez żadne ref lub reflog), jest nie ma możliwości odzyskania oryginalnej kopii-jest to trwałe cofnięcie. Care must być brane podczas korzystania z tego narzędzia, ponieważ jest to jedna z niewielu komend Git, która może stracić pracę.

Z https://www.atlassian.com/git/tutorials/undoing-changes/git-reset

I to

Na poziomie commit, resetowanie jest sposobem na przeniesienie wierzchołka gałęzi do innego / align = "left" / Można to wykorzystać do usunięcia commitów z bieżącej gałęzi.

Od https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations{[19]

należy pamiętać, że jest to uproszczone wyjaśnienie przeznaczone jako pierwszy krok w poszukiwaniu zrozumienia tej złożonej funkcjonalności.

Może być pomocny dla wizualnych uczniów, którzy chcą wizualizować jak wygląda ich stan projektu po każdym z tych poleceń:

Dla tych, którzy używają terminala z włączonym kolorem (Git config --global color.UI auto):

git reset --soft A i zobaczysz rzeczy B I C na Zielono (zainscenizowane i gotowe do popełnienia)

git reset --mixed A (lub git reset A) i zobaczysz rzeczy B I C w kolorze czerwonym (unstaged i gotowe do inscenizacji (zielony), a następnie popełnione)

git reset --hard A i nie będziesz już widział zmian B I C gdziekolwiek (będzie tak, jakby nigdy nie istniały)

git reset --soft A i zobaczysz rzeczy B I C w obszarze' zainscenizowane pliki ' gotowe do zatwierdzenia

git reset --mixed A (lub git reset A) i zobaczysz rzeczy B I C w obszarze' unstaged files ' gotowe do być przeniesione do inscenizacji, a następnie popełnione

git reset --hard A i nie będziesz już widział zmian B I C gdziekolwiek (będzie tak, jakby nigdy nie istniały)

Checkout wskazuje głowę na konkretny commit.

Reset wskazuje gałąź na określony commit. (Gałąź jest wskaźnikiem do commita.)

nawiasem mówiąc, jeśli Twoja głowa nie wskazuje na commit, który jest również wskazywany przez gałąź, to masz odłączoną głowę. _{(okazało się, że się myli. Zobacz komentarze...)}