Git jest git: Cofnięcie wypchniętego commita

Sytuacja jest prosta – chcemy wycofać ostatni, już push’nięty commit z repozytorium. Aby tego dokonać należy:

  1. Cofnąć lokalne repozytorium o jeden commit
    git reset --hard HEAD~1
  2. Wykonać force-push do zdalnego repozytorium
    git push -f origin Sprint5/SON-234

Aby operacja zakończyła się sukcesem, to na docelowym branchu musi być dozwolona modyfikacja historii repozytorium (odznaczona opcja Prevent rewriting history). Warto tutaj również wspomnieć, iż nie zalecane jest stosować tej praktyki na głównym branchu, lecz tylko na feature branchach.

undo-pushed-commit


Revert

Jeśli uprawnienia na branchu nie zezwalają na modyfikację historii, to nie pozostaje nic innego jak revert, czyli utworzenie commita odwracającego zmiany. W tym wypadku należy:

  1. Utworzyć commit cofający zmiany
    git revert HEAD

    GIT automatycznie zasugeruje opis commita w postaci: Revert “xxx”

  2. Wypchnąć zmiany do zdalnego repozytorium
    git push

revert-pushed-commit

Podbij ↑

Facebook
Twitter
LinkedIn
Google+
http://kurzyniec.pl/blog/cofniecie-wypchnietego-commita/

8 thoughts on “Git jest git: Cofnięcie wypchniętego commita

  1. Brakuje tylko informacji, że pierwszego podejście nie powinno się stosować, jeśli nie chce się narobić problemów reszcie zespołu. Nadpisywanie historii zdalnego repozytorium nie należy do ‘good practice’

    • Znaczy jest informacja ze dozwolone na feature branch-ach… ale to w praktyce… tylko przy kolejnym zalozeniu ze feature branche sa per osoba…

      I tu nie chodzi tylko o ‘good practice’ tylko o katastrofy, ktore z tego moga wyniknac, z utrata kodu wlacznie.

    • Zgadzam się w 100%, git reset hard może być niebezpieczny, szczególnie przy remote repos gdy chcemy później wypuszować zmiany.

      U nas sprawdza się jedynie przy continous ingegration i dostępnie do repo do odczytu. Na serwerze dev jest przed pulem git reset, tak aby na wszelki wypadek przywrócić poprzedni stan repo. Często ktoś coś zmienił na szybko w plikach konfiguracyjnych i build dalej nie idzie.

  2. Jeśli ktoś robi code review z gerritem lub innym gitolubnym narzędziem (build+testy+recenzja kolegi) to problemy z pchnięciem złego kodu na mastera w dużej mierze da się wyeliminować.

    Co do feature branchy to muszę przyznać że często korzystam z git reset dlatego że lubię robić wiele commitów checkpoint’ów a przed pchnięciem na serwer najczęściej zamieniam jest w jeden właściwy commit (squash via git rebase -i). Warto tutaj wspomnieć też o poleceniu git reflog które nieraz już ratowało mnie z poważnych tarapatów – zwłaszcza jeżeli git reset wyciachał za dużo :)

Leave a Reply

Your email address will not be published. Required fields are marked *