 git - cofnięcie ostatniego commita |
  |
| git - cofnięcie ostatniego commita |
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 281 Pomógł: 3 Dołączył: 8.06.2009 Skąd: Kraków Ostrzeżenie: (0%) 
 |
Witajcie,
załóżmy że mam jedną gałąź i 10 commitów (repo zdalne + lokalne) doszedłem do wniosku że chce się cofnąć do 5 commita: wpisuję sobie git checkout hash_commita i jestem na nowej gałęzi detached from hash_commita teraz faktycznie wróciłem do tego commita którego chciałem pytanie tylko jak to połączyć z gałęzią master na której przed chwilą byłem i wypchnąć na serwer ? pushem chciałbym aby ostatecznie w repozytorium aktualną wersją była ta z 5 commita a inne wersje zostały zapomniane ew. mogą gdzieś tam być w pamięci ale aktualną wersją ma być 5 commit Dziękuję za pomoc (IMG:style_emoticons/default/wink.gif) |
 |
 
|
|
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%)
|
Jeśli jesteś na master i chcesz się cofnąć z commitami to
git reset --hard hash jeśli jesteś na master i chcesz zrobić merge z dev ale z hash no to git merge hash Ten post edytował Pyton_000 22.06.2015, 18:42:14 |
|
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 915 Pomógł: 210 Dołączył: 8.09.2009 Skąd: Tomaszów Lubelski/Wrocław Ostrzeżenie: (0%)
|
|
|
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 2 Dołączył: 23.06.2015 Ostrzeżenie: (0%)
|
Najpierw wróć do mastera
git co master Nastepnie wycofaj sie do 5 commita git reset --hard [5_commit_hash] Teraz wyślij stan do zdalnego repo git push --force [Adam W.] |
|
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 281 Pomógł: 3 Dołączył: 8.06.2009 Skąd: Kraków Ostrzeżenie: (0%)
|
Dziękuję Panowie za odpowiedzi ! (IMG:style_emoticons/default/wink.gif) mam jeszcze jedno pytanie, czy jest możliwość jakiegoś szybkiego wycofania się z comita ? tzn wypycham comita na serwer i wszystko się wali chce szybko cofnąć ostatniego commita jak to najlepiej zrobić ?
z tego co widzę najlepiej mieć 2 gałęzie jedna na której pracuje i druga która jest de facto kopią tej pierwszej ale przeznaczoną na serwer jeśli ostatni comit nie działa to przechodząc do pierwszej mogę pracować i zobaczyć co nie działa natomiast w drugiej cofam się do poprzedniego comita (git reset hash) i potem wypycham zmiany git push - ale podejrzewam że jest jakiś inny prostszy sposób na zarządzanie tymi commitami bo to dosyć słabe jest mieć gałąź produkcyjną która nic innego nie robi jak odwzorowuje stan serwera i za każdym razem trzeba ją mergować z gałęzią developerską tak sobie myślę... Oczywiście można wrócić do poprzedniego comita na głównej gałęzi i to wypchać tyle że wtedy nie mam możliwości przetestowania co nie działa bo usuwam niedziałający kod, hmm...... Ten post edytował marcus753 23.06.2015, 10:28:47 |
|
|
|
|
Post
#6
|
|
|
Grupa: Zarejestrowani Postów: 8 068 Pomógł: 1414 Dołączył: 26.10.2005 Ostrzeżenie: (0%)
|
http://nvie.com/posts/a-successful-git-branching-model/
A co do "cofania" z ostatniego commita to git revert tworzy odwrotne commity Ten post edytował Pyton_000 23.06.2015, 10:43:39 |
|
|
|
|
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 2 Dołączył: 23.06.2015 Ostrzeżenie: (0%)
|
Wycofanie spushowanego commita można wykonać:
git revert [bledny_commit_hash] Powyższe polecenie wycofuje błędny commit tworząc kolejny commit wycofujący. Jeśli koniecznie chcesz pracować na jednym repo produkcyjnym, to możesz po wycofaniu zrobić sobie brancha z wadliwego commita i tam poprawić błędy (nie tracisz kodu). git checkout -b poprawka [bledny_commit_hash] Po poprawie scalić mastera z branchem poprawy i wysłać pushem. Sugeruje jednak zrobić dwa repozytoria - jedno na produkcje, drugie na developerkę i jedno wspólne, zdalne repozytorium. Każdą nową przetestowaną funkcjonalność na developerce scalasz ze zdalnym masterem repo produkcji (na wypadek jakbyś z wielu miejsc pracował, albo wielu ludzi mogło produkcje modyfikować) Scalony działający kod z developerki wysyłasz pushem na zdalne repo. Pullujesz na repo produkcyjnym zmiany i gotowe. Tutaj jest opisane wycofywanie commita przed i po pushu: http://willwarren.com/2013/04/20/reverting...hing-to-remote/ Na dole artykułu linki do dokumentacji git tych poleceń z przykładami i objaśnieniem. [Adam W.] |
|
|
|
|
Post
#8
|
|
|
Grupa: Zarejestrowani Postów: 281 Pomógł: 3 Dołączył: 8.06.2009 Skąd: Kraków Ostrzeżenie: (0%)
|
@kchteam - dziękuję bardzo ! konkretne wpisy (IMG:style_emoticons/default/wink.gif)
spotkaliście się z czymś takim ? 1. robię sobie nowe repozytorium 2. tworzę plik 3. robię commit plik A 4. aktualizuje plik A 5. robie commit aktualizacji pliku A 6. próbuję wrócić do pierwszego commita (git revert hash_commit) i otrzymuje błąd: git revert <hash> error: could not revert <hash>... .emacs.d contents from ubuntu hp 15 hint: after resolving the conflicts, mark the corrected paths hint: with 'git add <paths>' or 'git rm <paths>' hint: and commit the result with 'git commit' powrót do wybranego commita nie jest wykonany, co ciekawe po wpisaniu git status czy git commit otrzymuję komunikat nothing to commit, working directory clean co robię źle ? |
|
|
|
|
Post
#9
|
|
|
Grupa: Zarejestrowani Postów: 4 Pomógł: 2 Dołączył: 23.06.2015 Ostrzeżenie: (0%)
|
Nie git checkout hash_commita, tylko:
git checkout -b nazwa_galezi hash_commita Na nazwa_galezi modyfikujesz do woli kod, commitujesz. Przełączasz się na mastera i robisz git merge nazwa_galezi Całość wysyłasz do zdalnego repo, gałąź nazwa_galezi usuwasz [Adam W.] |
|
|
|
|
|
Aktualny czas: 24.08.2025 - 00:48 |
