Jak „cofnąć” przywrócone zatwierdzenie Git?

Biorąc pod uwagę zmianę, która została zatwierdzona przy użyciu commit, a następnie cofnięta przy użyciu revert, jaki jest najlepszy sposób na cofnięcie tego cofnięcia?

Najlepiej byłoby to zrobić z nowym zatwierdzeniem, aby nie ponownie zapisywać historii.

Jeśli jeszcze nie wprowadziłeś tej zmiany, git reset --hard HEAD^

W przeciwnym razie cofnięcie przywracania jest całkowicie w porządku.

Innym sposobem jest git checkout HEAD^^ -- .i wtedy git add -A && git commit.

git cherry-pick <original commit sha>
Wykona kopię oryginalnego zatwierdzenia, zasadniczo ponownie stosując zatwierdzenie

Cofnięcie cofnięcia spowoduje to samo, z komunikatem zatwierdzania przez program Messier:
git revert <commit sha of the revert>

Każdy z tych sposobów pozwoli ci git pushbez zastępowania historii, ponieważ tworzy ona nowe zatwierdzenie po przywróceniu.
Podczas wpisywania zatwierdzenia sha zwykle potrzebujesz tylko pierwszych 5 lub 6 znaków:
git cherry-pick 6bfabc

Cofnięcie zatwierdzenia jest jak każde inne zatwierdzenie w git. Czyli możesz to cofnąć, jak w:

git revert 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746

Ma to oczywiście sens dopiero po wprowadzeniu zmian, a zwłaszcza wtedy, gdy nie można wymusić wypchnięcia gałęzi docelowej (co jest dobrym pomysłem na gałęzi głównej ). Jeśli zmiana nie została wprowadzona, po prostu wybierz polecenie „wiśnia”, cofnij lub po prostu usuń zatwierdzenie przywrócenia, jak w przypadku innych postów.

W naszym zespole mamy zasadę korzystania z cofania w zatwierdzeniach Revert, które zostały popełnione w głównej gałęzi, przede wszystkim w celu utrzymania historii w czystości, abyś mógł zobaczyć, które zatwierdzenie przywraca co:

      7963f4b2a9d   Revert "Revert "OD-9033 parallel reporting configuration"
      "This reverts commit a0e5e86d3b66cf206ae98a9c989f649eeba7965f.
                    ...
     a0e5e86d3b6    Revert "OD-9055 paralel reporting configuration"
     This reverts commit 648d7d808bc1bca6dbf72d93bf3da7c65a9bd746.
                ...
     Merge pull request parallel_reporting_dbs to master* commit 
    '648d7d808bc1bca6dbf72d93bf3da7c65a9bd746'

W ten sposób możesz prześledzić historię i odkryć całą historię, a nawet ci bez wiedzy o spuściźnie mogliby sami to wypracować. Natomiast jeśli wybierzesz wiśni lub rebase rzeczy, to cenna informacja jest tracona (chyba, że włączenie go w komentarzu).

Oczywiście, jeśli zatwierdzenie cofnęło się i cofnęło więcej niż raz, staje się to dość nieuporządkowane.

Cofnięcie cofnięcia załatwi sprawę

Na przykład,

Jeśli abcdefjest to twoje zatwierdzenie i ghijkljest to potwierdzenie, które masz po cofnięciu zatwierdzenia abcdef, uruchom:

git revert ghijkl

Spowoduje to cofnięcie cofnięcia

Dla mnie to wygląda głupio. Byłem jednak w tej samej sytuacji i cofnąłem się, aby wycofać zatwierdzenia. Zrobiłem liczbę zmian, więc musiałem cofać dla każdego „cofnięcia zatwierdzenia”.

Teraz moja historia zobowiązań wygląda trochę dziwnie.

To jest projekt dla zwierząt, więc jest OK. Ale w przypadku projektu z prawdziwego życia wolałbym przejść do ostatniego zatwierdzenia przed przywróceniem przywrócić cały przywrócony kod razem w jednym zatwierdzeniu i bardziej rozsądnym komentarzu.

Oto jak to zrobiłem:
jeśli gałąź my_branchnamezostała uwzględniona w scaleniu, które zostało cofnięte. I chciałem cofnąćmy_branchname :

Najpierw robię git checkout -b my_new_branchnameod my_branchname.
Następnie robię, git reset --soft $COMMIT_HASHgdzie $COMMIT_HASHjest hash zatwierdzenia zatwierdzenia tuż przed pierwszym zatwierdzeniem my_branchname(patrz git log).
Następnie dokonuję nowego zatwierdzenia, a git commit -m "Add back reverted changes"
następnie wypycham nowy oddział, a git push origin new_branchname
następnie wysłałem żądanie ściągnięcia dla nowego oddziału.

Lub możesz git checkout -b <new-branch>i git cherry-pick <commit>wcześniej do i git rebaseupuścić revertzatwierdzenia. wyślij żądanie ściągnięcia jak poprzednio.

Jeśli nie podoba ci się pomysł „cofnięcia przywrócenia” (szczególnie gdy oznacza to utratę informacji historycznych dla wielu zatwierdzeń), zawsze możesz udać się do dokumentacji git na temat „Przywracania błędnego scalenia” .

Biorąc pod uwagę następującą sytuację wyjściową

 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E   <-- fixed-up topic branch

(W to początkowe cofnięcie scalenia M; D i E są poprawkami do początkowo uszkodzonej gałęzi / zatwierdzenia funkcji)

Teraz możesz po prostu odtwarzać zmiany od A do E, aby żadne z nich nie „należało” do odwróconego scalenia:

$ git checkout E
$ git rebase --no-ff P

Nowa kopia oddziału może teraz zostać masterponownie połączona z :

   A'---B'---C'------------D'---E'  <-- recreated topic branch
  /
 P---o---o---M---x---x---W---x
  \         /
   A---B---C----------------D---E

Aby odzyskać zmiany etapowe i etapowe, które zostały cofnięte po zatwierdzeniu:

git reset HEAD@{1}

Aby odzyskać wszystkie nieetapowe usunięcia:

git ls-files -d | xargs git checkout --