Szukaj…
Cofanie scala
Cofanie scalania jeszcze nie zostało przekazane do pilota
Jeśli jeszcze nie wysłałeś scalenia do zdalnego repozytorium, możesz wykonać tę samą procedurę, co w przypadku cofania zatwierdzenia, chociaż istnieją pewne subtelne różnice.
Reset jest najprostszą opcją, ponieważ cofnie zarówno zatwierdzenie scalania, jak i wszelkie zatwierdzenia dodane z gałęzi. Musisz jednak wiedzieć, do czego zresetować SHA, może to być trudne, ponieważ Twój git log będzie teraz wyświetlał zatwierdzenia z obu gałęzi. Jeśli zresetujesz do niewłaściwego zatwierdzenia (np. Jeden w drugim oddziale) , może to zniszczyć popełnioną pracę.
> git reset --hard <last commit from the branch you are on>
Lub, zakładając, że scalenie było ostatnim zatwierdzeniem.
> git reset HEAD~
Przywracanie jest bezpieczniejsze, ponieważ nie niszczy popełnionej pracy, ale wymaga więcej pracy, ponieważ musisz cofnąć przywrócenie, aby móc ponownie połączyć gałąź (zobacz następną sekcję).
Cofanie scalania zostało przekazane do pilota
Załóżmy, że łączysz się w nową funkcję (add-gremlins)
> git merge feature/add-gremlins
...
#Resolve any merge conflicts
> git commit #commit the merge
...
> git push
...
501b75d..17a51fd master -> master
Następnie odkrywasz, że funkcja, którą właśnie scaliłeś, złamała system dla innych programistów, należy go natychmiast cofnąć, a samo naprawienie tej funkcji potrwa zbyt długo, więc po prostu chcesz cofnąć scalenie.
> git revert -m 1 17a51fd
...
> git push
...
17a51fd..e443799 master -> master
W tym momencie gremliny są poza systemem, a twoi znajomi programiści przestali na ciebie krzyczeć. Jednak jeszcze nie skończyliśmy. Po rozwiązaniu problemu z funkcją add-gremlins konieczne będzie cofnięcie tego przywracania, zanim będzie można ponownie połączyć.
> git checkout feature/add-gremlins
...
#Various commits to fix the bug.
> git checkout master
...
> git revert e443799
...
> git merge feature/add-gremlins
...
#Fix any merge conflicts introduced by the bug fix
> git commit #commit the merge
...
> git push
W tym momencie Twoja funkcja została pomyślnie dodana. Jednak biorąc pod uwagę, że tego typu błędy są często wprowadzane przez konflikty scalania, nieco inny przepływ pracy jest czasem bardziej pomocny, ponieważ pozwala naprawić konflikt scalania w oddziale.
> git checkout feature/add-gremlins
...
#Merge in master and revert the revert right away. This puts your branch in
#the same broken state that master was in before.
> git merge master
...
> git revert e443799
...
#Now go ahead and fix the bug (various commits go here)
> git checkout master
...
#Don't need to revert the revert at this point since it was done earlier
> git merge feature/add-gremlins
...
#Fix any merge conflicts introduced by the bug fix
> git commit #commit the merge
...
> git push
Korzystanie z reflogu
Jeśli spieprzysz rebase, jedną z opcji, aby zacząć od nowa, jest powrót do zatwierdzenia (pre rebase). Możesz to zrobić za pomocą reflog (który zawiera historię wszystkiego, co zrobiłeś przez ostatnie 90 dni - można to skonfigurować):
$ git reflog
4a5cbb3 HEAD@{0}: rebase finished: returning to refs/heads/foo
4a5cbb3 HEAD@{1}: rebase: fixed such and such
904f7f0 HEAD@{2}: rebase: checkout upstream/master
3cbe20a HEAD@{3}: commit: fixed such and such
...
Możesz zobaczyć zatwierdzenie, zanim rebase był HEAD@{3} (możesz także sprawdzić hash):
git checkout HEAD@{3}
Teraz tworzysz nowy oddział / usuwasz stary / spróbuj ponownie dokonać zmiany bazy.
Możesz także zresetować bezpośrednio z powrotem do punktu w swoim reflog logowania, ale rób to tylko wtedy, gdy masz 100% pewności, że to, co chcesz zrobić:
git reset --hard HEAD@{3}
Spowoduje to ustawienie twojego obecnego drzewa git na dopasowanie do tego, jak było w tym momencie (patrz Cofanie zmian).
Można tego użyć, jeśli chwilowo widzisz, jak dobrze działa gałąź, gdy bazuje na innej gałęzi, ale nie chcesz zachować wyników.
Wróć do poprzedniego zatwierdzenia
Aby wrócić do poprzedniego zatwierdzenia, najpierw znajdź skrót zatwierdzenia za pomocą git log .
Aby tymczasowo skoczyć z powrotem do tego zatwierdzenia, odłącz głowę za pomocą:
git checkout 789abcd
To umieszcza cię w commit 789abcd . Możesz teraz dokonywać nowych zatwierdzeń na podstawie tego starego zatwierdzenia bez wpływu na gałąź, w której znajduje się głowa. Wszelkie zmiany można wprowadzić we właściwą gałąź za pomocą branch lub checkout -b .
Aby cofnąć się do poprzedniego zatwierdzenia, zachowując zmiany:
git reset --soft 789abcd
Aby cofnąć ostatnie zatwierdzenie:
git reset --soft HEAD~
Aby trwale odrzucić wszelkie zmiany wprowadzone po określonym zatwierdzeniu, użyj:
git reset --hard 789abcd
Aby trwale odrzucić wszelkie zmiany wprowadzone po ostatnim zatwierdzeniu:
git reset --hard HEAD~
Uwaga: chociaż można odzyskać odrzucone zatwierdzenia za pomocą reflog i reset , niezatwierdzonych zmian nie można odzyskać. Użyj git stash; git reset zamiast git reset --hard aby być bezpiecznym.
Cofanie zmian
Cofnij zmiany do pliku lub katalogu w kopii roboczej .
git checkout -- file.txt
Używany we wszystkich ścieżkach plików, rekurencyjnie z bieżącego katalogu, cofnie wszystkie zmiany w kopii roboczej.
git checkout -- .
Aby cofnąć tylko część zmian, użyj --patch . Przy każdej zmianie zostaniesz zapytany, czy należy ją cofnąć, czy nie.
git checkout --patch -- dir
Aby cofnąć zmiany dodane do indeksu .
git reset --hard
Bez flagi --hard spowoduje to miękki reset.
W przypadku lokalnych zatwierdzeń, które nie zostały jeszcze przekazane do pilota, można również wykonać miękki reset. W ten sposób możesz przerobić pliki, a następnie zatwierdzenia.
git reset HEAD~2
Powyższy przykład odwija ostatnie dwa zatwierdzenia i zwraca pliki do kopii roboczej. Następnie możesz wprowadzić dalsze zmiany i nowe zatwierdzenia.
Uwaga: wszystkie te operacje, oprócz miękkich resetów, trwale usuwają twoje zmiany. Dla bezpieczniejszej opcji użyj odpowiednio git stash -p lub git stash . Możesz później cofnąć za pomocą stash pop lub usunąć na zawsze za pomocą stash drop .
Cofnij niektóre istniejące zatwierdzenia
Użyj git revert, aby przywrócić istniejące zatwierdzenia, szczególnie gdy te zatwierdzenia zostały wypchnięte do zdalnego repozytorium. Rejestruje kilka nowych zatwierdzeń, aby odwrócić efekt niektórych wcześniejszych zatwierdzeń, które można bezpiecznie wypchnąć bez przepisywania historii.
Nie używaj git push --force chyba że chcesz obniżyć opprobrium wszystkich innych użytkowników tego repozytorium. Nigdy nie przepisuj historii publicznej.
Jeśli na przykład właśnie wypchnąłeś zatwierdzenie zawierające błąd i musisz go wycofać, wykonaj następujące czynności:
git revert HEAD~1
git push
Teraz możesz cofnąć zatwierdzenie przywracania lokalnie, naprawić swój kod i przekazać dobry kod:
git revert HEAD~1
work .. work .. work ..
git add -A .
git commit -m "Update error code"
git push
Jeśli zatwierdzenie, które chcesz przywrócić, znajduje się już w historii, możesz po prostu przekazać skrót zatwierdzenia. Git utworzy przeciw-zatwierdzenie cofając oryginalne zatwierdzenie, które możesz bezpiecznie wcisnąć do pilota.
git revert 912aaf0228338d0c8fb8cca0a064b0161a451fdc
git push
Cofnij / Ponów serię zatwierdzeń
Załóżmy, że chcesz cofnąć kilkanaście zmian i chcesz tylko niektóre z nich.
git rebase -i <earlier SHA>
-i przełącza rebase w „tryb interaktywny”. Zaczyna się tak, jak opisany powyżej rebase, ale przed odtworzeniem jakichkolwiek zatwierdzeń zatrzymuje się i pozwala delikatnie modyfikować każde zatwierdzenie podczas jego odtwarzania. rebase -i otworzy się w domyślnym edytorze tekstu z zastosowaną listą zatwierdzeń, jak poniżej: 
Aby upuścić zatwierdzenie, po prostu usuń ten wiersz w edytorze. Jeśli nie chcesz już niepoprawnych zatwierdzeń w projekcie, możesz usunąć wiersze 1 i 3-4 powyżej. Jeśli chcesz połączyć dwa zatwierdzenia razem, możesz użyć poleceń squash lub fixup 