Jak przywrócić z obecnego stanu do migawki wykonanej przy określonym zatwierdzeniu?
Jeśli tak git log
, to otrzymuję następujące dane wyjściowe:
$ git log
commit a867b4af366350be2e7c21b8de9cc6504678a61b`
Author: Me <[email protected]>
Date: Thu Nov 4 18:59:41 2010 -0400
blah blah blah...
commit 25eee4caef46ae64aa08e8ab3f988bc917ee1ce4
Author: Me <[email protected]>
Date: Thu Nov 4 05:13:39 2010 -0400
more blah blah blah...
commit 0766c053c0ea2035e90f504928f8df3c9363b8bd
Author: Me <[email protected]>
Date: Thu Nov 4 00:55:06 2010 -0400
And yet more blah blah...
commit 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
Author: Me <[email protected]>
Date: Wed Nov 3 23:56:08 2010 -0400
Yep, more blah blah.
Jak powrócić do zatwierdzenia od 3 listopada, tj. Zatwierdzenia 0d1d7fc
?
git
git-checkout
git-reset
git-revert
Szalony Serb
źródło
źródło
Odpowiedzi:
Wiele zależy od tego, co rozumiesz przez „cofnięcie”.
Tymczasowo przełącz na inne zatwierdzenie
Jeśli chcesz tymczasowo wrócić do niego, wygłupiać się, a następnie wrócić do tego, gdzie jesteś, wszystko, co musisz zrobić, to sprawdzić pożądane zatwierdzenie:
Lub jeśli chcesz dokonywać zatwierdzeń, gdy tam jesteś, idź i stwórz nowy oddział, gdy jesteś przy nim:
Aby wrócić do miejsca, w którym byłeś, po prostu sprawdź gałąź, w której byłeś. (Jeśli dokonałeś zmian, jak zwykle podczas zmiany gałęzi, będziesz musiał sobie z nimi poradzić, jeśli to konieczne. Możesz zresetować, aby je wyrzucić; możesz ukryć, wykupić, ukryć pop, aby zabrać je ze sobą; możesz zatwierdzić je do oddziału tam, jeśli chcesz tam oddziału.)
Twarde usuwanie niepublikowanych zatwierdzeń
Z drugiej strony, jeśli naprawdę chcesz pozbyć się wszystkiego, co zrobiłeś od tego czasu, są dwie możliwości. Po pierwsze, jeśli nie opublikowałeś żadnego z tych zatwierdzeń, po prostu zresetuj:
Jeśli się zepsujesz, już wyrzuciłeś swoje lokalne zmiany, ale możesz przynajmniej wrócić do poprzedniego stanu, resetując ponownie.
Cofnij opublikowane zatwierdzenia z nowymi zatwierdzeniami
Z drugiej strony, jeśli opublikowałeś pracę, prawdopodobnie nie chcesz zresetować gałęzi, ponieważ to skutecznie przepisuje historię. W takim przypadku rzeczywiście można cofnąć zatwierdzenia. W Git revert ma bardzo konkretne znaczenie: utwórz zatwierdzenie z odwrotną łatką, aby go anulować. W ten sposób nie przepisujesz żadnej historii.
Strona
git-revert
podręcznika zawiera wiele z tego w swoim opisie. Innym przydatnym linkiem jest ta sekcja git-scm.com omawiająca git-revert .Jeśli zdecydujesz, że mimo wszystko nie chcesz przywracać, możesz przywrócić przywrócenie (jak opisano tutaj) lub przywrócić do stanu sprzed przywrócenia (patrz poprzednia sekcja).
Pomocna może być również ta odpowiedź:
Jak przenieść HEAD z powrotem do poprzedniej lokalizacji? (Odłączona głowa)
źródło
git revert HEAD~3
jak najlepszej wat powrócić3
zobowiązuje AM jest ważne umowy.git reset --hard 0d1d7fc32e5a947fbd92ee598033d85bfc445a50
git revert --no-commit hash1 hash2 ...
a następnie po prostu zatwierdzić każdegit commit -m "Message"
Wiele skomplikowanych i niebezpiecznych odpowiedzi tutaj, ale w rzeczywistości jest to łatwe:
Spowoduje to przywrócenie wszystkiego z HEAD z powrotem do skrótu zatwierdzenia, co oznacza, że odtworzy ten stan zatwierdzenia w drzewie roboczym tak, jakby każde zatwierdzenie od czasu cofnięcia. Następnie możesz zatwierdzić bieżące drzewo, a utworzy ono nowe zatwierdzenie zasadniczo równoważne zatwierdzeniu, do którego „przywróciłeś”.
(
--no-commit
Flaga pozwala gitowi cofnąć wszystkie zatwierdzenia naraz - w przeciwnym razie zostaniesz poproszony o komunikat dla każdego zatwierdzenia w zakresie, zaśmiecając twoją historię niepotrzebnymi nowymi zatwierdzeniami).Jest to bezpieczny i łatwy sposób na przywrócenie poprzedniego stanu . Żadna historia nie jest niszczona, więc można jej użyć do zatwierdzeń, które zostały już upublicznione.
źródło
--no-edit
zamiast--no-commit
, abyś nie musiał edytować komunikatu zatwierdzenia dla każdej zmiany.git diff --cached
.$ git revert --no-commit 53742ae..HEAD
zwracafatal: empty commit set passed
81bcc9e HEAD{0}; e475924 HEAD{1}, ...
(zgit reflog
) i chciałem cofnąć to, co zrobiłem81bcc9e
, a potem musiałem to zrobićgit revert e475924..HEAD
Rogue Coder?
Pracujesz sam i chcesz, żeby działało? Postępuj zgodnie z poniższymi instrukcjami, od lat działają niezawodnie dla mnie i wielu innych.
Pracujesz z innymi? Git jest skomplikowane. Przeczytaj komentarze poniżej tej odpowiedzi, zanim zrobisz coś pochopnego.
Przywracanie kopii roboczej do najnowszego zatwierdzenia
Aby powrócić do poprzedniego zatwierdzenia, ignorując wszelkie zmiany:
gdzie HEAD jest ostatnim zatwierdzeniem w twoim bieżącym oddziale
Przywracanie kopii roboczej do starszego zatwierdzenia
Aby powrócić do zatwierdzenia, które jest starsze niż najnowsze zatwierdzenie:
Kredyty trafiają do podobnego pytania dotyczącego przepełnienia stosu. Czy powrócić do zatwierdzenia przez skrót SHA w Git? .
źródło
git reset --hard 56e05fc; git reset --soft HEAD@{1}; git commit
.Najlepszą opcją dla mnie i prawdopodobnie innych jest opcja resetowania Git:
To była dla mnie najlepsza opcja! To jest proste, szybkie i skuteczne!
Również z komentarzy, jeśli chciałbyś zastosować mniej „kulistą” metodę, której możesz użyć
źródło
git push -f
flagi ... Ale uważaj, to zastąpi pilota .. Upewnij się, że wiesz, co chcesz zrobić ...Zanim odpowiemy, dodajmy tło, wyjaśniając, co to
HEAD
jest.First of all what is HEAD?
HEAD
jest po prostu odniesieniem do bieżącego zatwierdzenia (najnowszego) w bieżącej gałęzi. WHEAD
danym momencie może być tylko jeden (wyłączającgit worktree
).Zawartość
HEAD
jest przechowywana w środku.git/HEAD
i zawiera 40 bajtów SHA-1 bieżącego zatwierdzenia.detached HEAD
Jeśli nie korzystasz z ostatniego zatwierdzenia - to znaczy
HEAD
to, nazywa się to wcześniejszym zatwierdzeniem w historiidetached HEAD
.W wierszu poleceń będzie to wyglądać tak - SHA-1 zamiast nazwy gałęzi, ponieważ
HEAD
nie wskazuje ona końcówki bieżącej gałęzi:Kilka opcji odzyskiwania po odłączeniu HEAD:
git checkout
Spowoduje to pobranie nowej gałęzi wskazującej żądany zatwierdzenie. To polecenie pobierze do danego zatwierdzenia.
W tym momencie możesz utworzyć gałąź i od tego momentu zacząć pracować:
git reflog
Zawsze możesz użyć
reflog
.git reflog
wyświetli każdą zmianę, która została zaktualizowana,HEAD
a sprawdzenie żądanego wpisu ponownego logowania spowoduje ustawienieHEAD
powrót do tego zatwierdzenia.Za każdym razem, gdy HEAD zostanie zmodyfikowany, pojawi się nowy wpis w
reflog
Spowoduje to powrót do żądanego zatwierdzenia
git reset HEAD --hard <commit_id>
„Przesuń” głowę z powrotem do żądanego zatwierdzenia.
git rebase --no-autostash
.Ten schemat ilustruje, które polecenie robi co. Jak widać,
reset && checkout
zmodyfikujHEAD
.źródło
git reflog
, właśnie tego potrzebowałemgit reset HEAD^
--hard`Jeśli chcesz „odrzucić”, skasować ostatni komunikat zatwierdzenia i przywrócić zmodyfikowane pliki do przemieszczania, użyj polecenia:
--soft
wskazuje, że niezatwierdzone pliki powinny zostać zachowane jako pliki robocze, w przeciwieństwie do plików--hard
nich, które je odrzuciłyby.HEAD~1
jest ostatnim zatwierdzeniem. Jeśli chcesz wycofać 3 zatwierdzenia, możesz użyćHEAD~3
. Jeśli chcesz przywrócić do określonego numeru wersji, możesz to zrobić również przy użyciu skrótu SHA.Jest to niezwykle przydatne polecenie w sytuacjach, w których popełniłeś błąd i chcesz cofnąć to ostatnie zatwierdzenie.
Źródło: http://nakkaya.com/2009/09/24/git-delete-last-commit/
źródło
Możesz to zrobić za pomocą następujących dwóch poleceń:
Spowoduje to usunięcie poprzedniego zatwierdzenia Git.
Jeśli chcesz zachować zmiany, możesz także użyć:
Następnie zapisze twoje zmiany.
źródło
Próbowałem wielu sposobów, aby przywrócić lokalne zmiany w Git i wydaje się, że działa to najlepiej, jeśli chcesz po prostu przywrócić ostatni stan zatwierdzenia.
Krótki opis:
git revert
robi.git checkout <commithashcode>
robi.Znalazłem znacznie wygodniejszy i prostszy sposób na osiągnięcie powyższych wyników:
gdzie HEAD wskazuje na ostatnie zatwierdzenie w twoim aktualnym oddziale.
Jest to ten sam kod, co sugerowany przez boulder_ruby, ale dodałem
git add .
wcześniej,git reset --hard HEAD
aby usunąć wszystkie nowe pliki utworzone od czasu ostatniego zatwierdzenia, ponieważ większość ludzi spodziewa się, że powrócę do ostatniego zatwierdzenia.źródło
OK, powrót do poprzedniego zatwierdzenia w Git jest dość łatwy ...
Cofnij się bez zachowywania zmian:
Wróć z zachowaniem zmian:
Objaśnienie: using
git reset
można zresetować do określonego stanu. Powszechnie używa się go z hashem zatwierdzającym, jak widać powyżej.Ale jak widzisz, różnica polega na użyciu dwóch flag
--soft
i--hard
domyślniegit reset
użyciu--soft
flagi, ale dobrą praktyką jest zawsze używanie flagi, wyjaśniam każdą flagę:--miękki
Domyślna flaga, jak wyjaśniono, nie musi jej dostarczać, nie zmienia działającego drzewa, ale dodaje wszystkie zmienione pliki gotowe do zatwierdzenia, więc wracasz do stanu zatwierdzenia, który zmiany w plikach stają się niestabilne.
--ciężko
Uważaj na tę flagę. Resetuje działające drzewo i wszystkie zmiany w śledzonych plikach i wszystko zniknie!
Stworzyłem również poniższy obraz, który może się zdarzyć w prawdziwym życiu podczas pracy z Git:
źródło
git reset
jestgit reset --mixed
, niegit reset --soft
. Sprawdź, jaka jest różnica między git reset --mixed, --soft i --hard? i w prostym języku angielskim, co robi „git reset”?Zakładając, że mówisz o mistrzu i w tej gałęzi (powiedział, że może to być dowolna działająca gałąź, o którą się martwisz):
Znalazłem odpowiedź w poście na blogu (teraz już nie istnieje)
Zauważ, że jest to resetowanie i wymuszanie zmiany na pilocie, więc jeśli inni w twoim zespole już to zrobili, spowodujesz dla nich problemy. Niszczycie historię zmian, co jest ważnym powodem, dla którego ludzie używają git w pierwszej kolejności.
Lepiej użyć cofania (zobacz inne odpowiedzi) niż resetowania. Jeśli jesteś drużyną jednoosobową, prawdopodobnie nie ma to znaczenia.
źródło
Załóżmy, że masz następujące zatwierdzenia w pliku tekstowym o nazwie
~/commits-to-revert.txt
(kiedyśgit log --pretty=oneline
je otrzymywałem)Utwórz skrypt powłoki Bash, aby przywrócić każdy z nich:
Spowoduje to przywrócenie wszystkiego do poprzedniego stanu, w tym tworzenie i usuwanie plików i katalogów, zatwierdzanie ich w oddziale i zachowanie historii, ale przywrócono ją do tej samej struktury plików. Dlaczego Git nie ma a
git revert --to <hash>
jest poza mną.źródło
git revert HEAD~3
aby usunąć ostatnie 3 zatwierdzeniagit revert -n master~3..master~1
zadziała? (Jak widać z kernel.org/pub/software/scm/git/docs/git-revert.html )git revert --no-commit <start>..<end>
, ponieważgit revert
akceptuje zakres zatwierdzania w nowych (lub wszystkich?) Wersjach Gita. Pamiętaj, że początek zakresu nie jest uwzględniony w cofnięciu.Dodatkowe alternatywy dla rozwiązań Jefromi
Rozwiązania Jefromi są zdecydowanie najlepsze i zdecydowanie powinieneś ich używać. Jednak ze względu na kompletność chciałem również pokazać te inne alternatywne rozwiązania, których można również użyć do cofnięcia zatwierdzenia (w tym sensie, że tworzysz nowe zatwierdzenie, które anuluje zmiany w poprzednim zatwierdzeniu , tak jak
git revert
robi to ).Żeby było jasne, te alternatywy nie są najlepszym sposobem na cofnięcie zatwierdzeń , rozwiązania Jefromi są , ale chcę tylko podkreślić, że możesz również użyć tych innych metod, aby osiągnąć to samo, co
git revert
.Alternatywa 1: Resety twarde i miękkie
To jest bardzo nieznacznie zmodyfikowana wersja rozwiązania Charlesa Baileya dotyczącego przywracania zatwierdzenia przez skrót SHA w Git? :
Zasadniczo działa to na podstawie faktu, że miękkie resetowanie pozostawi stan poprzedniego zatwierdzenia przemieszczonego w obszarze indeksu / przemieszczania, który można następnie zatwierdzić.
Alternatywa 2: Usuń bieżące drzewo i zastąp je nowym
To rozwiązanie pochodzi od rozwiązania Svicka do Checkout starego zatwierdzenia i uczyni go nowym zatwierdzeniem :
Podobnie jak w wariancie nr 1, odtwarza to stan
<commit>
w bieżącej kopii roboczej. Należy to zrobićgit rm
najpierw, ponieważgit checkout
nie usunie plików, które zostały dodane od tego czasu<commit>
.źródło
git revert HEAD~2..HEAD
z @ (@ Jefromi'S) połączonego rozwiązania Kaskabel użytkownika. Nie widzę problemu.Oto znacznie prostszy sposób na powrót do poprzedniego zatwierdzenia (i pozostawienie go w niezaangażowanym stanie, aby zrobić z nim cokolwiek zechcesz):
Nie trzeba więc podawać identyfikatorów i tak dalej :)
źródło
Istnieje polecenie (nie jest częścią podstawowego Git, ale znajduje się w pakiecie git-dodatków ) specjalnie do przywracania i ustawiania starych commits:
Na stronie podręcznika może być również używany jako taki:
źródło
Najlepszym sposobem jest:
Spowoduje to zresetowanie gałęzi do konkretnego zatwierdzenia, a następnie załaduje serwer zdalny z tymi samymi zatwierdzeniami, co w lokalnym (całkowicie wyeliminuje to polecenia po tym konkretnym zatwierdzeniu)
Uważaj, aby
--force
flaga usuwa wszystkie kolejne zatwierdzenia po wybranym zatwierdzeniu bez opcji ich odzyskania.źródło
Po wprowadzeniu wszystkich zmian po naciśnięciu wszystkich tych poleceń może być konieczne użycie:
I nie tylko
git push
.źródło
Możesz wykonać wszystkie te wstępne kroki samodzielnie i wypchnąć z powrotem do repozytorium Git.
Pobierz najnowszą wersję swojego repozytorium z Bitbucket za pomocą
git pull --all
polecenia.Uruchom polecenie Git log za pomocą
-n 4
poziomu terminala. Liczba po-n
określa liczbę zatwierdzeń w dzienniku, zaczynając od ostatniego zatwierdzenia w lokalnej historii.Zresetuj nagłówek historii swojego repozytorium, używając
git reset --hard HEAD~N
N gdzie liczba zatwierdzeń, którą chcesz cofnąć. W poniższym przykładzie nagłówek cofnąłby jeden zatwierdzenie do ostatniego zatwierdzenia w historii repozytorium:Wciśnij zmianę do repozytorium Git za pomocą
git push --force
aby wymusić zmianę.Jeśli chcesz, aby repozytorium Git zawierało poprzednie zatwierdzenie:
źródło
Powróć do ostatniego zatwierdzenia i ignorując wszystkie zmiany lokalne:
źródło
Wybierz wymagane zatwierdzenie i sprawdź przez
dopóki nie otrzymasz wymaganego zatwierdzenia. Aby HEAD wskazywał na to, zrób to
lub
git reset --hard HEAD~2
cokolwiek.źródło
git show HEAD
jest to równoznaczne z samym użyciemgit log HEAD -1
.Jeśli sytuacja jest pilna , a chcesz po prostu zrobić to, o co pytający pytał w szybki i brudny sposób, zakładając, że twój projekt znajduje się w katalogu o nazwie na przykład „mój projekt”:
SZYBKIE I BRUDNE : w zależności od okoliczności, szybkie i brudne mogą być naprawdę DOBRE. Moje rozwiązanie tutaj NIE zastępuje nieodwracalnie plików, które masz w katalogu roboczym, plikami wyciągniętymi / wyodrębnionymi z głębi repozytorium git czającym się pod twoim katalogiem .git / za pomocą diabelnie sprytnych i diabolicznie potężnych poleceń git, których są wiele. NIE MUSISZ ROBIĆ TAKIEGO NURKOWANIA NA GŁĘBOKIM MORZU, ABY ODZYSKAĆ coś, co może się wydawać katastrofalną sytuacją, a próba zrobienia tego bez wystarczającej wiedzy specjalistycznej może okazać się śmiertelna .
Skopiuj cały katalog i nazwij go czymś innym, na przykład „mój projekt - skopiuj”. Zakładając, że pliki repozytorium git („repo”) znajdują się w katalogu „mój projekt” (ich domyślne miejsce, w katalogu o nazwie „.git”), skopiujesz teraz zarówno pliki robocze, jak i pliki repo.
Zrób to w katalogu „mój projekt”:
Spowoduje to przywrócenie stanu repozytorium w „moim projekcie” do stanu, w którym dokonano tego zatwierdzenia („zatwierdzenie” oznacza migawkę plików roboczych). Wszystkie zatwierdzenia od tego czasu zostaną utracone na zawsze pod „moim projektem”, ALE ... nadal będą obecne w repozytorium pod „moim projektem - skopiuj”, ponieważ skopiowałeś wszystkie te pliki - w tym te pod… /. Git /.
Masz wtedy dwie wersje w swoim systemie ... możesz sprawdzać, kopiować lub modyfikować interesujące Cię pliki lub cokolwiek innego, z poprzedniego zatwierdzenia. Możesz całkowicie odrzucić pliki w obszarze „mój projekt - skopiuj”, jeśli zdecydowałeś się na nową pracę, ponieważ przywrócone zatwierdzenie nigdzie nie poszło ...
Oczywistą rzeczą jest to, że jeśli chcesz kontynuować stan projektu bez faktycznego odrzucenia pracy, ponieważ to odzyskane zatwierdzenie polega na ponownej zmianie nazwy katalogu: Usuń projekt zawierający odzyskane zatwierdzenie (lub nadaj mu tymczasową nazwę) i zmień nazwę swojego „ mój projekt - skopiuj „katalog z powrotem do„ mojego projektu ”. Więc może spróbuj zrozumieć niektóre z innych odpowiedzi tutaj i prawdopodobnie wkrótce wykonasz kolejne zatwierdzenie.
Git jest genialnym dziełem, ale absolutnie nikt nie jest w stanie po prostu „odebrać go w locie”: także ludzie, którzy zbyt często próbują to wyjaśnić zakładają wcześniejszą wiedzę o innych systemach kontroli wersji VCS i sięgają za daleko zbyt wcześnie i popełniaj inne przestępstwa, takie jak używanie wymiennych terminów do „sprawdzania” - w sposób, który czasami wydaje się prawie wyliczony, by wprowadzić w błąd początkującego.
Aby zaoszczędzić sobie stresu, ucz się od moich blizn. Musisz przeczytać książkę na temat Gita - polecam „Kontrola wersji z Git” . Zrób to wcześniej niż później. Jeśli tak, pamiętaj, że duża część złożoności Git wynika z rozgałęziania, a następnie ponownego łączenia się: możesz pominąć te części w dowolnej książce. Z twojego pytania nie ma powodu, dla którego ludzie powinni cię oślepiać nauką .
Zwłaszcza jeśli, na przykład, jest to desperacka sytuacja i jesteś nowicjuszem w Git!
PS: Jeszcze jedna myśl: w rzeczywistości (obecnie) bardzo łatwo jest przechowywać repozytorium Git w katalogu innym niż ten z działającymi plikami. Oznaczałoby to, że nie musisz kopiować całego repozytorium Git przy użyciu powyższego szybkiego i brudnego rozwiązania. Zobacz odpowiedź Fryer za pomocą
--separate-git-dir
tutaj . Ostrzegamy jednak: jeśli masz repozytorium „osobnego katalogu”, którego nie kopiujesz i wykonujesz twardy reset, wszystkie wersje następujące po zatwierdzeniu resetowania zostaną utracone na zawsze, chyba że masz, jak absolutnie powinieneś, regularnie tworzył kopie zapasowe repozytorium, najlepiej w chmurze (np. na Dysku Google ).W tym temacie „tworzenia kopii zapasowych w chmurze” następnym krokiem jest otwarcie konta (oczywiście za darmo) w GitHub lub (co moim zdaniem) w GitLab . Następnie możesz regularnie wykonywać
git push
polecenia, aby aktualizowanie repozytorium Cloud było „prawidłowe”. Ale znowu mówienie o tym może być za dużo za wcześnie.źródło
Jest to jeszcze jeden sposób na bezpośrednie zresetowanie do ostatniego zatwierdzenia
Bezpośrednio usuwa wszystkie zmiany, które wprowadziłeś od ostatniego zatwierdzenia.
PS: Ma mały problem; usuwa również wszystkie ostatnio zapisane zmiany skrytki. Co w większości przypadków nie powinno mieć znaczenia.
źródło
Aby całkowicie wyczyścić katalog programisty z przypadkowych zmian, użyliśmy:
Po prostu
git reset --hard HEAD
pozbędzie się modyfikacji, ale nie pozbędzie się „nowych” plików. W ich przypadku przypadkowo przeciągnęli ważny folder gdzieś losowo, a wszystkie te pliki były traktowane przez Git jako nowe, więcreset --hard
nie naprawiono tego. Uruchamiającgit add -A .
wcześniej, jawnie śledził je wszystkie za pomocą git, aby zostały usunięte przez reset.źródło
Aby zachować zmiany z poprzedniego zatwierdzenia do HEAD i przejść do poprzedniego zatwierdzenia, wykonaj:
Jeśli zmiany nie są wymagane od poprzedniego zatwierdzenia w HEAD i po prostu odrzuć wszystkie zmiany, wykonaj:
źródło
Wierzę, że niektórzy ludzie mogą przyjść na to pytanie, chcąc wiedzieć, jak cofnąć zatwierdzone zmiany, które wprowadzili w swoim mistrzu - tj. Wyrzucić wszystko i wrócić do origin / master, w takim przypadku wykonaj następujące czynności:
/superuser/273172/how-to-reset-master-to-origin-master
źródło
Cofnij to polecenie wycofania zatwierdzeń.
Próba:
git revert 2h3h23233
Może mierzyć zasięg HEAD jak poniżej. Tutaj 1 mówi „cofnij ostatnie zatwierdzenie”.
git revert HEAD~1..HEAD
a następnie zrobić
git push
źródło
Spróbuj zresetować do żądanego zatwierdzenia -
git reset <COMMIT_ID>
(aby sprawdzić użycie COMMIT_ID
git log
)Spowoduje to zresetowanie wszystkich zmienionych plików do stanu bez dodania.
Teraz możesz
checkout
wszystkie pliki, które nie zostały dodane przezgit checkout .
Sprawdź,
git log
aby zweryfikować zmiany.AKTUALIZACJA
Jeśli masz tylko jedno zatwierdzenie w repozytorium, spróbuj
git update-ref -d HEAD
źródło
Ponieważ twoje zatwierdzenia są wypychane zdalnie, musisz je usunąć. Załóżmy, że twoja gałąź się rozwija i jest zepchnięta na pochodzenie .
Najpierw musisz usunąć wywoływanie z pochodzenia :
Następnie musisz rozwinąć się do pożądanego stanu, pozwól mi założyć, że skrótem zatwierdzenia jest EFGHIJK:
Wreszcie, push rozwijaj ponownie:
źródło
Miałem podobny problem i chciałem wrócić do wcześniejszego zatwierdzenia. W moim przypadku nie byłem zainteresowany zachowaniem nowszego zatwierdzenia, dlatego skorzystałem
Hard
.Oto jak to zrobiłem:
Spowoduje to przywrócenie lokalnego repozytorium, a tutaj po użyciu
git push -f
zaktualizuje zdalne repozytorium.źródło
W GitKraken możesz to zrobić:
Kliknij prawym przyciskiem myszy na zatwierdzenie, które chcesz zresetować, wybierz: Zresetuj do tego zatwierdzenia / Hard :
Kliknij ponownie zatwierdzenie prawym przyciskiem myszy, wybierz: Bieżąca nazwa oddziału / Wciśnij :
Kliknij na Force Push :
Obs. : Musisz być ostrożny, ponieważ cała historia zatwierdzeń po twardym resecie zostaje utracona, a działanie to jest nieodwracalne. Musisz być pewien, co robisz.
źródło
Jeśli chcesz poprawić błąd w ostatnim zatwierdzeniu, dobrą alternatywą byłoby użycie polecenia git commit --amend . Jeśli ostatnie zatwierdzenie nie jest wskazywane przez żadne odniesienie, to załatwi sprawę, ponieważ tworzy zatwierdzenie z tym samym rodzicem, co ostatnie zatwierdzenie. Jeśli nie ma odniesienia do ostatniego zatwierdzenia, zostanie po prostu odrzucone, a to zatwierdzenie będzie ostatnim zatwierdzeniem. Jest to dobry sposób korygowania zatwierdzeń bez cofania zatwierdzeń. Ma jednak swoje ograniczenia.
źródło