Sytuacja jest prosta – chcemy wycofać ostatni, już push’nięty commit z repozytorium. Aby tego dokonać należy:
- Cofnąć lokalne repozytorium o jeden commit
git reset --hard HEAD~1
- Wykonać force-push do zdalnego repozytorium
git push -f origin feature/SON-234
Aby operacja zakończyła się sukcesem, to na docelowym branchu musi być dozwolona modyfikacja historii repozytorium. Warto tutaj również wspomnieć, iż niezalecane jest stosować tej praktyki na głównym branchu, lecz tylko na feature branchach.
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:
- Utworzyć commit cofający zmiany
git revert HEAD
GIT automatycznie zasugeruje opis commita w postaci: Revert „xxx”
- Wypchnąć zmiany do zdalnego repozytorium
git push
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’
Chyba ze msz god-mode wlaczone, wtedy mozesz wszystko :)
Marcin, Paweł,
Macie rację, pierwsze podejście stosuję tylko i wyłącznie na feature branchach.
Poprawione, dzięki! :)
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.
Arek,
Zgadza się, może dojść do utraty kodu. Ale skoro GIT daje taką możliwość, to czemu by nie skorzystać z tego. Oczywiście z głową i rozwagą!
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.
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 :)
Marcin,
Dzięki za cenne wskazówki, na pewno coś wykorzystam. Kolejnym moim krokiem jest squash :)