Usuń określone zatwierdzenie


287

Pracowałem z przyjacielem nad projektem, a on edytował kilka plików, których nie powinno się edytować. W jakiś sposób połączyłem jego prace z moimi, albo kiedy je wyciągnąłem, albo gdy próbowałem po prostu wybrać konkretne pliki, które chciałem. Od dłuższego czasu szukam i gram, próbując wymyślić, jak usunąć zatwierdzenia zawierające edycje tych plików, wydaje się, że jest to podrzucenie między revert i rebase, i nie ma prostych przykładów, a Dokumenty zakładają, że wiem więcej niż ja.

Oto uproszczona wersja pytania:

Biorąc pod uwagę następujący scenariusz, jak usunąć commit 2?

$ mkdir git_revert_test && cd git_revert_test

$ git init
Initialized empty Git repository in /Users/josh/deleteme/git_revert_test/.git/

$ echo "line 1" > myfile

$ git add -A

$ git commit -m "commit 1"
[master (root-commit) 8230fa3] commit 1
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ echo "line 2" >> myfile

$ git commit -am "commit 2"
[master 342f9bb] commit 2
 1 files changed, 1 insertions(+), 0 deletions(-)

$ echo "line 3" >> myfile

$ git commit -am "commit 3"
[master 1bcb872] commit 3
 1 files changed, 1 insertions(+), 0 deletions(-)

Oczekiwany wynik to

$ cat myfile
line 1
line 3

Oto przykład tego, jak próbowałem przywrócić

$ git revert 342f9bb
Automatic revert failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result.

5
Jeśli ktoś to znajdzie, szukając tego samego problemu, oto co skończyłem: Kopiuj i wklej. Poważnie. Ponad 6 godzin spędziłem na próbach uzyskania sugerowanych rozwiązań, ale bezskutecznie. W końcu zabrakło mi czasu, wyciągnąłem oryginał i po prostu skopiowałem / wkleiłem około 20 plików. Zajęło to mniej niż 5 minut i od tamtej pory wszystko było w porządku (nawet gdy te pliki są scalane ze zmianami w innych gałęziach, które miały miejsce przed tym fiaskiem). Proponuję również przyjąć to podejście. Nie tylko jest to najprostsze, ale podejrzewam, że to jedyna rzecz, która działa.
Joshua Cheek

Miałem do czynienia z podobnym problemem, ale być może bardziej złożonym: miałem oddział z setkami zmian, które chciałem zgnieść. Niestety zatwierdzenia z innej gałęzi zostały scalone z powrotem do gałęzi w punkcie pośrednim, więc konieczne było „odczepienie”, zanim mogłem zgnieść. Poszedłem ścieżką podobną do sugerowanej przez tk poniżej (wybieranie wiśni + przy użyciu notacji zakresu), ale spowodowało konflikty w niektórych innych plikach. Na koniec skopiuj i wklej + kilka ręcznych zmian było najłatwiejszą i najbardziej przewidywalną ścieżką do przodu. Zdecydowanie warte rozważenia, jeśli spędzasz na tym zbyt dużo czasu.
Federico

Odpowiedzi:


73

Algorytm używany przez Git podczas obliczania różnic, które mają zostać cofnięte, wymaga tego

  1. cofane linie nie są modyfikowane przez żadne późniejsze zatwierdzenia.
  2. że nie będzie żadnych innych „sąsiadujących” zobowiązań w dalszej części historii.

Definicja „sąsiadującego” opiera się na domyślnej liczbie linii z różnic kontekstowych, która wynosi 3. Więc jeśli „mój plik” został skonstruowany w ten sposób:

$ cat >myfile <<EOF
line 1
junk
junk
junk
junk
line 2
junk
junk
junk
junk
line 3
EOF
$ git add myfile
$ git commit -m "initial check-in"
 1 files changed, 11 insertions(+), 0 deletions(-)
 create mode 100644 myfile

$ perl -p -i -e 's/line 2/this is the second line/;' myfile
$ git commit -am "changed line 2 to second line"
[master d6cbb19] changed line 2
 1 files changed, 1 insertions(+), 1 deletions(-)

$ perl -p -i -e 's/line 3/this is the third line/;' myfile
$ git commit -am "changed line 3 to third line"
[master dd054fe] changed line 3
 1 files changed, 1 insertions(+), 1 deletions(-)

$ git revert d6cbb19
Finished one revert.
[master 2db5c47] Revert "changed line 2"
 1 files changed, 1 insertions(+), 1 deletions(-)

Wtedy wszystko działa zgodnie z oczekiwaniami.

Druga odpowiedź była bardzo interesująca. Istnieje funkcja, która nie została jeszcze oficjalnie wydana (chociaż jest dostępna w Git v1.7.2-rc2) o nazwie Revert Strategy. Możesz wywołać git w ten sposób:

git revert --strategy resolver <commit>

i powinna lepiej zrozumieć, o co ci chodziło. Nie wiem, jaka jest lista dostępnych strategii, ani nie znam definicji żadnej strategii.


1
perl -pjest przydatny do pisania bardzo krótkich programów (jedna linia), które zapętlają i przekazują dane wejściowe do wyjścia, podobnie jak sed. perl -isłuży do edycji plików w miejscu . perl -ejest jak przesłać kod do oceny .
Hal Eisen

281

Można to zrobić na cztery sposoby:

  • Czysty sposób, cofanie, ale zaloguj się cofnij:

    git revert --strategy resolve <commit>
    
  • Ostry sposób, usuń w całości tylko ostatni zatwierdzenie:

    git reset --soft "HEAD^"
    

Uwaga: Unikaj, git reset --hardponieważ spowoduje także odrzucenie wszystkich zmian w plikach od ostatniego zatwierdzenia. Jeśli --softnie działa, spróbuj --mixedlub --keep.

  • Rebase (pokaż dziennik ostatnich 5 zatwierdzeń i usuń wiersze, których nie chcesz, lub zmień kolejność, lub zmiksuj wiele zatwierdzeń w jednym lub zrób cokolwiek innego, jest to bardzo wszechstronne narzędzie):

    git rebase -i HEAD~5
    

A jeśli popełnisz błąd:

git rebase --abort
  • Szybki rebase: usuń tylko określony zatwierdzenie, używając jego identyfikatora:

    git rebase --onto commit-id^ commit-id
    
  • Alternatywy: możesz także spróbować:

    git cherry-pick commit-id
    
  • Jeszcze jedna alternatywa:

    git revert --no-commit
    
  • W ostateczności, jeśli potrzebujesz pełnej swobody edytowania historii (np. Ponieważ git nie pozwala ci edytować tego, co chcesz), możesz użyć tej bardzo szybkiej aplikacji typu open source: reposurgeon .

Uwaga: oczywiście wszystkie te zmiany są wprowadzane lokalnie, należy git pushnastępnie zastosować zmiany do pilota. A jeśli twoje repozytorium nie chce usunąć zatwierdzenia („niedozwolone szybkie przewijanie do przodu”, co dzieje się, gdy chcesz usunąć zatwierdzenie, które już wypchnąłeś), możesz użyć git push -fwymuszania wypchnięcia zmian.

Uwaga 2: jeśli pracujesz nad gałęzią i musisz wymusić wypychanie, powinieneś absolutnie tego unikać, git push --forceponieważ może to zastąpić inne gałęzie (jeśli dokonałeś w nich zmian, nawet jeśli bieżąca kasa znajduje się w innej gałęzi). Wolą zawsze określić zdalną gałąź, kiedy wymusić Push : git push --force origin your_branch.


Na podstawie sugestii @gaborous: zrób „git rebase -i HEAD ~ 2”. Teraz masz kilka opcji. W vimie możesz zobaczyć kilka komentowanych linii: jedna z nich mówi ci, że możesz po prostu usunąć linię (która powinna być zmianą, której chcesz się pozbyć), a ta zmiana zostanie usunięta wraz z dziennikiem w twojej historii.
Ilker Cat

git revert --strategy resolver <commit>. Ta komenda działała dla mnie. dzięki :)
Swathin

2
git rebase -i HEAD~5pracował dla mnie. Następnie usunąłem zatwierdzenia, których nie potrzebowałem i mogłem rozwiązać problem w mniej niż 30 sekund. Dziękuję Ci.
lv10

118

Oto proste rozwiązanie:

git rebase -i HEAD~x

(Uwaga: xjest liczbą zatwierdzeń)

po uruchomieniu plik notatnika otworzy się. Wpisz dropoprócz zatwierdzenia.
Jeśli nie znasz Vima, po prostu kliknij każde słowo, które chcesz edytować, a następnie naciśnij klawisz „I” (dla trybu wstawiania). Po zakończeniu pisania naciśnij klawisz „esc”, aby wyjść z trybu wstawiania.



wprowadź opis zdjęcia tutaj

i to wszystko, gotowe! Zsynchronizuj pulpit git, a zmiany zostaną przekazane zdalnie.

Jeśli upuszczone zatwierdzenie znajdowało się już na pilocie, będziesz musiał wymusić push. Ponieważ --force jest uważane za szkodliwe , użyj git push --force-with-lease.


Czy istnieje dobry sposób, aby dowiedzieć się, jakie powinno być „x”, jeśli znasz tylko skrót danego zatwierdzenia?
jlewkovich

1
Dla osób cpp-mentality: x (liczba zatwierdzeń) jest włącznie. np. HEAD ~ 4 obejmuje ostatnie 4 zatwierdzenia.
Herpes Free Engineer

idealna sugestia. po prostu chcę dodać, to także odrzuca zmiany z upuszczonego zatwierdzenia.
celerno

próbował cofnąć 3 zatwierdzenia: git rebase -i HEAD-3 dostał błąd krytyczny: Potrzebował jednej zmiany niepoprawnej w górę „HEAD-3”
Ustin

1
@Ustin to ~ 3 nie -3
JD-V

37

Twój wybór jest pomiędzy

  1. utrzymanie błędu i wprowadzenie poprawki oraz
  2. usunięcie błędu i zmiana historii.

Powinieneś wybrać (1), jeśli błędna zmiana została wykryta przez kogoś innego, i (2), jeśli błąd jest ograniczony do prywatnego nieprzesuniętego oddziału.

Git revert to zautomatyzowane narzędzie do zrobienia (1), tworzy nowe zatwierdzenie cofając niektóre poprzednie zatwierdzenia. Zobaczysz błąd i usunięcie w historii projektu, ale ludzie, którzy ściągną z twojego repozytorium, nie będą mieli problemów podczas aktualizacji. W twoim przykładzie nie działa to w sposób zautomatyzowany, więc musisz edytować „mój plik” (aby usunąć wiersz 2), zrobić git add myfilei git commitrozwiązać konflikt. Skończysz wtedy z czterema zatwierdzeniami w historii, z zatwierdzeniem 4 cofającym zatwierdzenie 2.

Jeśli nikogo nie obchodzi, że twoja historia się zmienia, możesz ją przepisać i usunąć zatwierdzenie 2 (wybór 2). Najłatwiejszym sposobem na to jest użycie git rebase -i 8230fa3. Spowoduje to przeniesienie Cię do edytora i możesz zdecydować, aby nie dołączać błędnego zatwierdzenia, usuwając zatwierdzenie (i zaznaczając opcję „wybierz” obok innych komunikatów zatwierdzenia. Przeczytaj o konsekwencjach takiego działania) .


Rebase może być trudne, ponieważ wygląda na to, że nastąpiło scalenie.
Cascabel

3
git rebase -i 8230fa3 i usunięcie wiersza zatwierdzenia działało dla mnie świetnie z moimi lokalnymi zmianami. Dzięki!
Samuel

26

Appproch 1

Najpierw pobierz skrót zatwierdzenia (np. 1406cd61), który musisz przywrócić. prosta poprawka będzie poniżej polecenia,

$ git revert 1406cd61

jeśli masz więcej zmian związanych z plikami 1406cd61 po 1406cd61, powyższe proste polecenie nie będzie działać. Następnie musisz wykonać poniższe kroki, czyli zbieranie wiśni.

Około 2

Wykonaj poniższe czynności, ponieważ używamy --force, aby to zrobić, musisz mieć uprawnienia administratora do repozytorium git.

Krok 1: Znajdź zatwierdzenie przed zatwierdzeniem, które chcesz usunąćgit log

Krok 2: Sprawdź to zatwierdzeniegit checkout <commit hash>

Krok 3: Utwórz nowy oddział przy użyciu bieżącego zatwierdzenia transakcjigit checkout -b <new branch>

Krok 4: Teraz musisz dodać zatwierdzenie po usuniętym zatwierdzeniugit cherry-pick <commit hash>

Krok 5: Teraz powtórz krok 4 dla wszystkich innych zatwierdzeń, które chcesz zachować.

Krok 6: Po dodaniu wszystkich zatwierdzeń do nowego oddziału i zatwierdzeniu. Sprawdź, czy wszystko jest we właściwym stanie i działa zgodnie z przeznaczeniem. Dokładnie sprawdź, czy wszystko zostało zatwierdzone:git status

Krok 7: Przejdź do zepsutej gałęzigit checkout <broken branch>

Krok 8: Teraz wykonaj twardy reset uszkodzonej gałęzi w celu zatwierdzenia przed tą, którą chcesz usunąćgit reset --hard <commit hash>

Krok 9: Scal swoją stałą gałąź w tę gałąźgit merge <branch name>

Krok 10: Przekaż scalone zmiany z powrotem do źródła. OSTRZEŻENIE: Zastąpi to zdalne repozytorium!git push --force origin <branch name>

Możesz wykonać ten proces bez tworzenia nowego oddziału, zastępując krok 2 i 3 krokiem 8, a następnie nie przeprowadzać kroków 7 i 9.


1
Pierwsze podejście działało jak urok. Zawiera zatwierdzenie określające, że żądane zatwierdzenie zostało cofnięte, co jest naprawdę przydatne do celów śledzenia.
suarsenegger

18

Możesz usunąć niechciane zatwierdzenia za pomocą git rebase. Załóżmy, że włączyłeś do swojej gałęzi tematów kilka gałęzi tematów współpracownika, ale później zdecydujesz, że nie chcesz tych zmian.

git checkout -b tmp-branch my-topic-branch  # Use a temporary branch to be safe.
git rebase -i master  # Interactively rebase against master branch.

W tym momencie edytor tekstu otworzy interaktywny widok bazy. Na przykład

git-rebase-todo

  1. Usuń niepotrzebne zatwierdzenia, usuwając ich wiersze
  2. Zapisz i wyjdź

Jeśli zmiana bazy nie powiodła się, usuń gałąź tymczasową i wypróbuj inną strategię. W przeciwnym razie postępuj zgodnie z następującymi instrukcjami.

git checkout my-topic-branch
git reset --hard tmp-branch  # Overwrite your topic branch with the temp branch.
git branch -d tmp-branch  # Delete the temporary branch.

Jeśli przekazujesz gałąź tematu do pilota, może być konieczne wymuszenie wypychania, ponieważ historia zmian uległa zmianie. Jeśli inni pracują nad tym samym oddziałem, daj im znać.


Czy możesz podać przykład „wypróbuj inną strategię”?
pfabri

@pfabri możesz na przykład wybrać dwa zakresy zatwierdzeń, w których pomijasz błędne zatwierdzenie. Możesz cofnąć złe zatwierdzenie. Można uniknąć korzystania z rozwiązania git, nawet ręcznie cofając zmiany lub rozpoczynając od nowej gałęzi bez złego zatwierdzenia i ręcznie powtarzając dobre zmiany. Jeśli złe zatwierdzenie zawiera poufne dane, będziesz potrzebować bardziej ostrożnej strategii: help.github.com/en/articles/…
Dennis

8

Z innych odpowiedzi tutaj byłem trochę zdezorientowany, jak git rebase -imożna go użyć do usunięcia zatwierdzenia, więc mam nadzieję, że zapisanie mojego testu tutaj jest tutaj (bardzo podobne do OP).

Oto bashskrypt, który możesz wkleić, aby utworzyć repozytorium testowe w /tmpfolderze:

set -x

rm -rf /tmp/myrepo*
cd /tmp

mkdir myrepo_git
cd myrepo_git
git init
git config user.name me
git config user.email me@myself.com

mkdir folder
echo aaaa >> folder/file.txt
git add folder/file.txt
git commit -m "1st git commit"

echo bbbb >> folder/file.txt
git add folder/file.txt
git commit -m "2nd git commit"

echo cccc >> folder/file.txt
git add folder/file.txt
git commit -m "3rd git commit"

echo dddd >> folder/file.txt
git add folder/file.txt
git commit -m "4th git commit"

echo eeee >> folder/file.txt
git add folder/file.txt
git commit -m "5th git commit"

W tym momencie mamy file.txtz tymi treściami:

aaaa
bbbb
cccc
dddd
eeee

W tym momencie HEAD jest na 5. zatwierdzeniu, HEAD ~ 1 będzie na 4. - a HEAD ~ 4 będzie na 1. zatwierdzeniu (więc HEAD ~ 5 nie istnieje). Powiedzmy, że chcemy usunąć 3. zatwierdzenie - możemy wydać to polecenie w myrepo_gitkatalogu:

git rebase -i HEAD~4

( Zauważ, że git rebase -i HEAD~5wyniki z „fatal: Potrzebowałem jednej wersji; niepoprawny HEAD ~ 5”. ) Otworzy się edytor tekstu (patrz zrzut ekranu w odpowiedzi @Dennis ) z następującymi treściami:

pick 5978582 2nd git commit
pick 448c212 3rd git commit
pick b50213c 4th git commit
pick a9c8fa1 5th git commit

# Rebase b916e7f..a9c8fa1 onto b916e7f
# ...

Otrzymujemy więc wszystkie zatwierdzenia od (ale nie wliczając ) naszej żądanej GŁOWICY ~ 4. Usuń linię pick 448c212 3rd git commiti zapisz plik; otrzymasz tę odpowiedź od git rebase:

error: could not apply b50213c... 4th git commit

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
Could not apply b50213c... 4th git commit

W tym momencie otwórz myrepo_git / folder/file.txtw edytorze tekstu; zobaczysz, że został zmodyfikowany:

aaaa
bbbb
<<<<<<< HEAD
=======
cccc
dddd
>>>>>>> b50213c... 4th git commit

Zasadniczo gitwidzi, że kiedy HEAD dotarł do drugiego zatwierdzenia, pojawiła się treść aaaa+ bbbb; a następnie ma łatkę dodaną cccc+, ddddktórej nie wie, jak dołączyć do istniejącej zawartości.

Więc tutaj gitnie możesz zdecydować za Ciebie - to ty musisz podjąć decyzję: usuwając 3. zatwierdzenie, albo zachowujesz wprowadzone przez niego zmiany (tutaj wiersz cccc) - albo nie. Jeśli nie, po prostu usuń dodatkowe wiersze - w tym cccc- przy folder/file.txtużyciu edytora tekstu, aby wyglądało to tak:

aaaa
bbbb
dddd

... a następnie zapisz folder/file.txt. Teraz możesz wydać następujące polecenia w myrepo_gitkatalogu:

$ nano folder/file.txt  # text editor - edit, save
$ git rebase --continue
folder/file.txt: needs merge
You must edit all merge conflicts and then
mark them as resolved using git add

Ach - tak aby zaznaczyć, że mamy rozwiązać konflikt, my musi , przed wykonaniem :git addfolder/file.txtgit rebase --continue

$ git add folder/file.txt
$ git rebase --continue

Tutaj ponownie otwiera się edytor tekstowy, pokazujący wiersz 4th git commit- tutaj mamy szansę zmienić komunikat zatwierdzenia (który w tym przypadku można znacznie zmienić na 4th (and removed 3rd) commitlub podobny). Powiedzmy, że nie chcesz - więc po prostu wyjdź z edytora tekstu bez zapisywania; gdy to zrobisz, otrzymasz:

$ git rebase --continue
[detached HEAD b8275fc] 4th git commit
 1 file changed, 1 insertion(+)
Successfully rebased and updated refs/heads/master.

W tym momencie masz teraz taką historię (którą możesz również sprawdzić za pomocą powiedz gitk .lub innymi narzędziami) zawartości folder/file.txt(z pozornie niezmienionymi znacznikami czasu oryginalnych zatwierdzeń):

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   dddd
                |  +eeee

A jeśli wcześniej postanowiliśmy zachować linię cccc(zawartość trzeciego git commit, którą usunęliśmy), mielibyśmy:

1st git commit  |  +aaaa
----------------------------------------------
2nd git commit  |   aaaa
                |  +bbbb
----------------------------------------------
4th git commit  |   aaaa
                |   bbbb
                |  +cccc
                |  +dddd
----------------------------------------------
5th git commit  |   aaaa
                |   bbbb
                |   cccc
                |   dddd
                |  +eeee

Cóż, tego rodzaju lekturę miałem nadzieję znaleźć, żeby zacząć się zastanawiać, jak git rebasedziała usuwanie skryptu ; więc mam nadzieję, że może to również pomóc innym ...


Co za nieocenione przejście - dokładny przypadek użycia, z którym walczyłem, bardzo mi to pomogło.
pfabri

2

Wygląda więc na to, że złe zatwierdzenie zostało w pewnym momencie włączone do zatwierdzenia scalania. Czy zatwierdzenie scalania zostało już wycofane? Jeśli tak, to będziesz chciał użyć git revert; będziesz musiał zacisnąć zęby i przejść przez konflikty. Jeśli nie, to możesz albo zmienić bazę, albo cofnąć, ale możesz to zrobić przed zatwierdzeniem scalania, a następnie powtórz scalenie.

Naprawdę niewiele możemy ci pomóc w pierwszym przypadku. Po wypróbowaniu przywracania i stwierdzeniu, że automatyczny nie powiódł się, musisz zbadać konflikty i odpowiednio je naprawić. Jest to dokładnie ten sam proces, co naprawianie konfliktów scalania; możesz użyć, git statusaby sprawdzić, gdzie znajdują się konflikty, edytować niepołączone pliki, znaleźć konfliktowe porcje, dowiedzieć się, jak je rozwiązać, dodać skonfliktowane pliki i wreszcie zatwierdzić. Jeśli używasz git commitsamego (nie -m <message>), komunikat, który pojawia się w twoim edytorze, powinien być szablonowym komunikatem utworzonym przez git revert; możesz dodać notatkę o tym, jak naprawiłeś konflikty, a następnie zapisać i wyjść z zatwierdzenia.

W drugim przypadku, rozwiązującym problem przed scaleniem, istnieją dwie podklasy, w zależności od tego, czy wykonałeś więcej pracy od scalenia. Jeśli tego nie zrobisz, możesz po prostu git reset --hard HEAD^przerwać scalanie, cofnąć, a następnie powtórzyć scalanie. Ale zgaduję, że masz. Więc skończysz robić coś takiego:

  • utwórz tymczasową gałąź tuż przed scaleniem i sprawdź ją
  • wykonaj cofnięcie (lub użyj, git rebase -i <something before the bad commit> <temporary branch>aby usunąć zły zatwierdzenie)
  • powtórz scalenie
  • oprzyj swoją kolejną pracę z powrotem na: git rebase --onto <temporary branch> <old merge commit> <real branch>
  • usuń gałąź tymczasową

1

Więc wykonałeś trochę pracy i przeforsowałeś je, nazwijmy je zobowiązaniami A i B. Twój współpracownik również wykonał trochę pracy, zobowiązuje się C i D. Połączyłeś pracę swoich współpracowników z twoimi (scalanie zatwierdzenia E), a następnie kontynuowałeś pracę, popełniłem to, też (popełnij F) i odkryłeś, że twój współpracownik zmienił pewne rzeczy, których nie powinien.

Twoja historia zmian wygląda następująco:

A -- B -- C -- D -- D' -- E -- F

Naprawdę chcesz pozbyć się C, D i D '. Ponieważ mówisz, że połączyłeś pracę swoich współpracowników z twoimi, te zatwierdzenia są już „tam”, więc usunięcie zatwierdzeń przy użyciu np. Git rebase jest nie-nie. Uwierz mi, próbowałem.

Teraz widzę dwa wyjścia:

  • jeśli jeszcze nie wypchnąłeś E i F do swojego współpracownika lub kogokolwiek innego (zazwyczaj do twojego serwera „pochodzenia”), możesz na razie usunąć je z historii. To jest twoja praca, którą chcesz zapisać. Można to zrobić za pomocą

    git reset D'
    

    (zamień D 'na rzeczywisty skrót zatwierdzenia, który możesz uzyskać z git log

    W tym momencie zatwierdzenia E i F zniknęły, a zmiany są ponownie niezatwierdzonymi zmianami w lokalnym obszarze roboczym. W tym momencie przeniosę je do gałęzi lub zamienię w łatkę i zachowam na później. Teraz cofnij pracę współpracownika, albo automatycznie, git revertalbo ręcznie. Gdy to zrobisz, powtórz swoją pracę nad tym. Możesz mieć konflikty scalania, ale przynajmniej będą one w kodzie, który napisałeś, zamiast kodu współpracownika.

  • Jeśli już wykonałeś pracę po popełnieniu przez współpracownika, nadal możesz spróbować uzyskać „odwrotną łatkę” ręcznie lub przy użyciu git revert, ale ponieważ twoja praca jest „na drodze”, więc tak powiem, prawdopodobnie dostaniesz więcej konfliktów scalania i bardziej zagmatwanych. Wygląda na to, że skończyłeś w ...


0

git revert - strategia rozwiązać, jeśli zatwierdzenie jest scaleniem: użyj git revert - strategia rozwiązać -m 1

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.