Git merge vs. rebase (i jak robić to dobrze)

[@radosawberlinski2567]

Super, tak samo jak "Git i GitHub w 60 minut". Oglądnąłem oba filmy, super wyjaśnione.

[@michadobrowolski5374]

Dla mnie mistrzowskie tłumaczenie :) Dzięki!

[@pwittchen]

Fajny filmik, ale nie do końca zgadzam się z takim modelem pracy z następujących powodów: - podczas developmentu cały czas trzeba rozpraszać się rebase'ami i rozwiązywaniem w tym czasie ewentualnych konfliktów; bez tego konflikty rozwiązujemy tylko raz na końcu - w podanym przykładzie pominąłeś merge commit; spotkałem się z sytuacjami, że z różnych powodów trzeba wycofać feature przed releasem i najłatwiej to zrobić revertując merge commit całego feature brancha; w przypadku takiego modelu pracy nie jest to możliwe - commity robione na feature branchu są commitami "pomocniczymi" podczas rozwijania danego featura (np. poprawki po code review itp.) i zaburzają historię projektu; lepiej przed pushem lub mergem do mastera zesquashować wszystkie commity z feature brancha do jednego - mamy wtedy czystą historię bez commitów "pomocniczych" - jeżeli następuje sytuacja, o której wspomniałeś, tzn. jest ogromny rozjazd pomiędzy feature branchem a masterem, nad którym nie da się zapanować to znaczy, że praca w zespole jest źle zorganizowana i ludzie grzebią w tym samym czasie w tych samych plikach lub metodach; konflikty powinny być rozwiązywalne i zdarzać się rzadko; takie kwestie powinny być rozwiązywane na etapie "ludzkim", a nie z poziomu gita Poza tym, spoko. Pozdrawiam :-)

[@JakNauczycSieProgramowania]

Bardzo ciekawa opinia, przypinam Twój komentarz, bo warto żeby więcej osób miało okazję zapoznać się z tym spojrzeniem :) Jak to bardzo często przy rozwiązywaniu problemów w IT bywa, tak i tutaj nie ma jednej, idealnej drogi, każdy ma swoje argumenty, przekonania, najważniejsze, żeby zespół zdecydował, jaki model pracy jest dla niego najbardziej właściwy, a potem trzeba już tylko dopilnować, żeby każdy z zespołu tego się trzymał :)

[@ellandill]

- rebase tez możesz robić raz końcu - czasami nie ma wyjścia jak codzienny rebase w przypadku bardzo dynamicznego rozwoju aplikacji - natomiast problemem jest że po pierwszym push nie za bardzo można już robić rebase a taki model że jeden push wystarczy i nie będzie uwag po review code działa może przy drobnych poprawkach

[@Eddyi0202]

@Piotr Wittchen "lepiej przed pushem lub mergem do mastera zesquashować wszystkie commity z feature brancha do jednego - mamy wtedy czystą historię bez commitów "pomocniczych" Czy to nie przesadzona praktyka żeby np. z 30 commitów robić jeden? Czy nie powinna jednak zostać jakaś historia zmian w postaci wielu commitów na takim branchu?

[@rt-li2de]

@@ellandill Jak nie można jak można i to działa

[@rt-li2de]

@@Eddyi0202 To właśnie daje rebase. Scalenie można zrobić operacją Combine to one commit

[@Kamil1561]

Bardzo dobrze tłumaczone, czekam na kolejne części z gita.

[@JakNauczycSieProgramowania]

A ten film: kzbin.info/www/bejne/e5PIandrr7eerK8 widziałeś? I jeżeli jesteś zainteresowany Gitem na jeszcze bardziej zaawansowanym poziomie, polecam mój kurs Git od podstaw: www.programujodpodstaw.pl/git-od-podstaw/

[@krzysztofs551]

Stare are jare - świetny materiał również w 2022!

[@MrFaciio]

Dziękuję bardzo za filmik, musiałem obejrzeć 2 razy, żeby zrozumieć różnicę pomiędzy merge/rebase i teraz wszystko jest dla mnie jasne! ♥

[@JakNauczycSieProgramowania]

Mega, najważniejsze, że już wszystko jasne!

[@chibithescorp]

Zamiast przełączać się cały czas pomiędzy branchami/masterem wystarczy na swoim feature_branch'u użyć "git pull origin master" i wszystkie zmiany z mastera-servera są w naszym branch'u. Co do rebase'a, to można i tak do tego podchodzić. Kwestia gustu.

[@JakNauczycSieProgramowania]

Bardzo merytoryczny komentarz, dzięki! Warto jednak upewnić się, że na naszym lokalnym masterze nie mamy zacommitowanych, a jeszcze nie wypushowanych na origina zmian. Oczywiście jeżeli trzymamy się właściwego workflowu taka sytuacja nie powinna mieć miejsca, ale niestety człowiek to istota, która popełnia czasem błędy ; )

[@marcelsztur9903]

dziękuje ci za te filmy są super. Tak dalej !

[@grzegorzko55]

Super wyjaśnione

[@jakubunold5750]

Bardzo przejrzyście wytłumaczone. Taki live-coding z przykładami na końcu uważam za bardzo skuteczną formę nauki - pokazuje, że nawet najlepsi nie zawsze piszą wszystko od razu poprawnie i nie ma co się obawiać próbować nowych rzeczy! Ciekawy komentarz @Piotra Wiitchen'a, jednak chyba spróbuję zastosować się do Twojej praktyki :)

[@KondzioTVstudio]

Fajnie wytlumaczone. Nie wiem jak winnych edytorach ale ja u siebie w Webstormie nie musze checkout robic do mastera by zrobic pull moge to wyklikac ale monza rowniez zamiast git checkout master zrobic git rebase orgin/master

[@tomekkuprowski5285]

Super wyjaśniłeś !

[@ewarystawecki3631]

Świetne!

[@marcinbiaecki9731]

Dzięki, bardzo przydatny film :)

[@panhilson]

elegancki materiał, pozdrawiam

[@JakNauczycSieProgramowania]

Dzięki!

[@piotr.kwiatkowski]

Bardzo sensowny filmik. Szanuję

[@JakNauczycSieProgramowania]

Dzięki!

[@deathlotos522]

Jestem na feature branchu, robie git rebase main --> wystepuja konflikty ktore naprawiam. Po "naprawie" trzeba zrobic commit (message np. "Fix merge conflicts" lub "Merge main") z naprawionymi konfliktami?

[@JakNauczycSieProgramowania]

Dokładnie tak 👍

[@Igoand03]

Dzięki za film. Przekaż bardzo zrozumiały :)

[@marekt8465]

Czy w 9:30 zamiast checkout'owac na mastera i zaciągać pullem zmiany i później znowu przechodzić na naszego brancha i wpisywać 'git rebase master' moglibyśmy na naszym branchu wpisać po prostu 'git pull --rebase'? Wyszłoby na to samo?

[@JakNauczycSieProgramowania]

Nie, bo wtedy zaciągnąłbyś zmiany tylko z tego brancha, na którym jesteś, a Ty chcesz zaciągnąć zmiany z mastera i na nie nałożyć zmiany, które masz na swoim branchu. Git pull nie zaciąga zmian z mastera, zaciąga zmiany z brancha, na którym aktualnie się znajdujesz.

[@RaZziaN1]

@@JakNauczycSieProgramowania To w sumie dobrze Marek napisal, tylko po --rebase dodac nazwe brancha z ktorego pullowac zmiany do aktualnego, wyjdzie na to samo.

[@karolinaswiergaa9537]

@@RaZziaN1 no a wtedy nie zostawiamy local mastera "w tyle"? Ja rozumiem to tak, że robiąc na sposób z filmiku updateujemy też naszego lokalnego mastera przy okazji. Jeśli jest inaczej to będę wdzięczna jak mnie ktoś poprawi i wytłumaczy

[@user-qc5vu7gi7c]

No ale dobra, mam dwa commity z innego brancha na masterze i co, jak je teraz wsadzić na ich miejsce, bo są na samej górze a ich zawartość jest starsza niż z najnowszego commita na masterze, powinniśmy chyba jakoś dwa commity z feature cofnąć do commit 1 i commit 2?

[@JakNauczycSieProgramowania]

To co jest już na masterze to rzecz święta - do mastera możesz tylko dodawać commity, w żadnym wypadku nie modyfikuj jego historii, bo to może mieć bardzo nieprzyjemne konsekwencje. Ktoś stworzy brancha z aktualnego mastera, będzie na nim pracował, Ty w międzyczasie zmienisz kolejność commitów na masterze i gdy ta druga osoba będzie chciała wrzucić na mastera swoje zmiany, nagle okaże się, że master wygląda już zupełnie inaczej. A gdy nad projektem będzie pracować kilka osób, to w moment zrobi się chaos nie do ogarnięcia. Jeżeli Ty stworzyłeś brancha z mastera, pracowałeś nad swoimi zmianami i chcesz je wrzucić do mastera, ale w międzyczasie ktoś dodał coś na mastera, to jest to jak najbardziej normalna sytuacja i właśnie dlatego robimy rebase (bo master od czasu, gdy stworzyliśmy naszego brancha już się zmienił). Także wchodzimy na mastera, robimy na nim git pull, żeby te zmiany zaciągnąć do nas, a następnie przechodzimy na nasz branch i robimy git rebase master. Wszystkie te zmiany, które pojawiły się w międzyczasie trafiają pod nasze commity, a nasze commity lądują na samej górze.

[@shikamaru4271]

Bardzo dobry film

[@krl0o]

Czy brancz to linia czasu a commity to poszczegulne abdejty? dobże zrozumiałem?

[@JakNauczycSieProgramowania]

Generalnie tak, ale zobacz jeszcze ten film, w którym dokładnie to wyjaśniam: kzbin.info/www/bejne/e5PIandrr7eerK8

[@krl0o]

dzieki

[@gosuroger]

Dzięki. Miałem takie pytanie na rozmowie kwalifikacyjnej na juniora. Gdybym widział ten filmik troszkę wcześniej.

[@JakNauczycSieProgramowania]

Cześć, szykuję teraz spore zmiany na kanale, także tego typu filmów będzie zdecydowanie więcej. Na początku nadchodzącego tygodnia zdradzę więcej szczegółów, ale jeżeli szykujesz się na juniora, to trafiłeś idealnie :) A jak poszła ta rozmowa? Jeszcze jakieś ciekawe pytania miałeś?

[@gosuroger]

@@JakNauczycSieProgramowania z gita miałem kilka pytań, z takich o których nie miałem pojęcia - pojawiło się pytanie właśnie o Rebase oraz o git stash. Niestety rozmowa nie poszła dobrze, zdecydowanie wyłożyłem się na teorii, bo praktyka poszła na wcześniejszych etapach dobrze. Z ciekawych pytań - pytali jeszcze o to, czy w Javie zmienne do metody są przekazywane przez wskaźnik, przez referencje, czy przez wartość.

[@JakNauczycSieProgramowania]

@@gosuroger O Gicie już niedługo będą kolejne filmy na kanale, więc i git stash i squashowanie commitów i parę innych ciekawych rzeczy się pojawi. Za pół roku żadna rozmowa kwalikacyjna już Cię nie zaskoczy ;)

[@replay_pete]

Witam. Próbuje nauczyć się obsługi gita /githuba i niejasna jest dla mnie do końca jedna kwestia. Proszę poprawić, jeśli źle zrozumiałem. Załóżmy, że sprawdziłem nowe zmiany na masterze i wróciłem już na swojego brancha. Jeżeli wpiszę na nim rebase master to kopiuję zmiany z mastera na swojego brancha czy też nie kopiuję ale mój branch staje się masterem i psuję wtedy robotę innym? Czy jest to możliwe?

[@JakNauczycSieProgramowania]

Robiąc rebase master na swoim branchu przenosisz na swojego brancha najnowsze commity z mastera (te, których jeszcze nie masz na swoim branchu). Twój branch nie może stać się masterem, bo nie mogą istnieć dwa branche o takiej samej nazwie. Musiałbyś najpierw zmienić nazwę mastera na jakąś inną (lub usunąć branch master) i zmienić nazwę swojego brancha na "master".

[@replay_pete]

@@JakNauczycSieProgramowania dziękuję za odpowiedź. W takim razie nie muszę się obawiać, że popsuje pracę innym.

[@maciej12345678]

są tez minusy rebase na publicznym repo

[@matTt3u52]

8:36 nie bylo uzycia -m (a -am)chcociaz byl to nowy plik a nie modyfikowany

[@edinn979]

Nie mogę zrozumieć czemu w ostatnim kroku używasz merge zamiast rebase, mógłbyś napisać czemu tak robisz ?

[@TheNoahStarr]

Legancko

[@matTt3u52]

u mnie po git pull jest Already up to date. i dalej te stare dwa commity na masterze. a po git branch master: Current branch features_branch is up to date...

[@matTt3u52]

dodalem cos do mastera i udalo sie :) Successfully rebased and updated refs/heads/features_branch.

[@krzysztofjedraszak8065]

dlaczego zrobiłeś w branchu feature rebase a pozniej jeszcze na masterze merge ? nie mozna by zrobic od razu na masterze rebase?

[@JakNauczycSieProgramowania]

Wtedy zrobiłbyś odwrotną operację - nowe commity z brancha master weszłyby na samą górę, a Ty podczas rebase'a chcesz, żeby na samej górze znalazły się commity z feature brancha. Załóżmy, że mamy brancha master z takimi commitami (nowsze wyżej): master 2 master 1 W tym momencie tworzymy branch o nazwie feature, więc mamy na nim takie same commity jak na masterze: master 2 master 1 Pracujemy sobie na naszym feature branchu i dodajemy commit o nazwie feature 1, otrzymując taką historię: feature 1 master 2 master 1 Przychodzi moment, kiedy trzeba wrzucić nasze zmiany na mastera, ale w tym czasie ktoś dodał już na mastera nowy commit i mamy na nim taką historię: master 3 master 2 master 1 I teraz jeżeli zrobimy tak jak na filmie: git checkout feature git rebase master Otrzymamy taką historię commitów: feature 1 master 3 master 2 master 1 Czyli nie zmieniamy historii brancha master i na samą górę dodajemy nasze commity z feature brancha. Za to gdybyśmy zrobili: git checkout master git rebase feature Otrzymalibyśmy: master 3 feature 1 master 2 master 1

[@krzysztofjedraszak8065]

@@JakNauczycSieProgramowania dzięki bardzo za wyjaśnienie, teraz już w pełni rozumiem

[@KS2416]

A czy mógłbyś omówić usuwanie i zamianę kolejności commitow po poleceniu git rebase - i HEAD?

[@JakNauczycSieProgramowania]

Tak, wrócę niedługo do tematu Gita i ten koncept też wytłumaczę :)

[@KS2416]

@@JakNauczycSieProgramowania A czy możesz mi podpowiedzieć o po tym poleceniu nie wiem jak wejść w ten tryb gdzie się wycina i wkleja commit i zmienia kolejnosc

[@JakNauczycSieProgramowania]

​@@KS2416 Najpierw git log, żeby zobaczyć historię commitów. Następnie kopiujesz hash ostatniego commita, którego chcesz zostawić bez ZMIAN. Powiedzmy, że jest to 01k21071. Teraz wykonujesz komendę git rebase -i 01k21071. Otwiera Ci się tryb, w którym możesz zmienić historię commitów przy pomocy takich opcji jak squash, fixup czy reword.

[@KS2416]

@@JakNauczycSieProgramowania dziekuje

[@czitels1856]

Fajny film, ale następnym razem zwiększ czcionkę w konsoli. Oglądałem na telefonie i musiałem bardzo przybliżyć ekran żeby zobaczyć.

[@JakNauczycSieProgramowania]

O tak, od tamtej pory wyciągnąłem wnioski 😃 teraz jak włączysz nowe filmy z tutorialami to już w zupełnie innej rozdzielczości nagrywam i wszystko widać!

[@kacperkepinski4990]

uja wiem

[@dawidzabielski3584]

Co to za muzyka w tle :D

[@JakNauczycSieProgramowania]

Zobaczę później czy mam zapisany tytuł i dam znać!

[@dawidzabielski3584]

@@JakNauczycSieProgramowania Skoro mam jakis maly kontakt. Oglądałem juz bardzo duzo filmów i zrobilem pare programów. Ale wciąż brakuje mi takiego.. Ułożenia. Czy była by szansa w przyszłości zrobic film o pracy front-end od kuchni? Mam na mysli typowy dzień na pracy zdalnej. Czyli dostanie jakiegos zlecenia. Pobranie elementow z Git, edycja czegos w pliku html jak i linkowanych w nim plikow JS i CSS i wrzucenie znow na GIT z sytuacją gdy ktos pracowal na tym samym pliku. (zakonczenie projektu) w zadaniach cos naprawde prostego. Ale glownym celem bylo by pokazanie jak wyglada typowe zlecenie. Dziękuję za odpowiedź. I dziękuję za to co robisz, zaczalem uczyc sie programowania od początku tego roku. A dzieki twoim filmom myślę, że szybko uda mi sie wejść we Front-End.

[@JakNauczycSieProgramowania]

@@dawidzabielski3584 Co do muzy to instrumentalna wersja utworu Sam Kramer - Racks on Racks: kzbin.info/www/bejne/bquzmKJ8pJaVjK8 Jeżeli chodzi o typowy dzień pracy, to postaram się coś takiego nagrać :) A nowy odcinek o Gicie oglądałeś? Bo pokazywałem w nim właśnie jak rozwiązywać konflikty, gdy dwie osoby pracowały z tym samym plikiem: kzbin.info/www/bejne/e5PIandrr7eerK8 Mega, że zacząłeś się uczyć programowania! Od czego zacząłeś i jaki masz plan?

[@dawidzabielski3584]

@@JakNauczycSieProgramowania Dzięki za odpowiedź co do muzyki. Tak oglądałem, lacznie z wczorajszym filmem. Caly twoj kanał ogarniety. Co do planu. Staram sie wejść we front-end. Tak wiec od poczatku roku nie wiedząc nic na temat programowania. Stwierdzilem ze dobrze bedzie zrozumiec najpierw o co w tym chodzi. Bez uczenia sie konkretnego jezyka. Chcę opanowac jezyki programowania i patrzec na nie tylko jako narzędzia. A nie ogarniac tylko jednego jezyka lub dwóch. Puki co ogarnialem twoj kanał, kanał Mirosława Zelend'a (ale tu jest problem z programowaniem w czasach 2010/2014, czlowiek dobrze opisuje, ale dzis sa nowe lepsze rozwiazania), jak i Overment (jednak tutaj naplyw materialu jest za duzy. A raczej przeskok w stopniu trudnosci. Po 30min kursu nie wiedzialem juz nawet jak mam na imie.) u ciebie jest spokojny, wolniejszy i zrozumialy sposob wszystko przekazywane. To dlatego tu zostalem. Brakuje mi jednak w calej gamie filmow na YT. Serii filmow. Typowych zadań. Chodzi mi o filmy gdzie ktos bazujacy na HTML, JS, CSS, API, GIT, pokaze serie zadań. Np. Jak zrobic samo przesowne w prawo, okno na stronie. Jak robic zakladki. Jak zrobic aby pobrac informacje od klienta w ramach rejestracji, wyslac przez api na serwer, sprawdzic obecnosc, wysłać mail z potwierdzeniem rejestracji. Zadania które sa juz typowo robocze. Wiem ze to jak podanie na tacy wszystkiego. Ale jak to ujołeś "Lepsze niz uczenie sie na bledach, jest ich nie popełnianie." Wracajac do planu, siedze po 6h do 12h dziennie po pracy. Ogladajac tutoriale i kodujac. Zamierzam szkolic sie ogolowo cos jak full stack. Tak aby pozniej widziec problemy nie tylko na poziomie 2ch jezykow. Zamierzam do kwietnia stworzyć swoja strone jako nawiazanie do CV i rozpoczac szukanie pracy pod koniec kwietnia. Tak wiec tempo duże. Do tej pory programowalem maszyny pomiarowe dla firmy Lotniczej. Ale ta branża w okresie pandemii upada. Wiec czas na zmiane pracy. Stąd motywacja.

[@dawidzabielski3584]

Wybacz, że tak sie rozpisałem. Ale zależy mi na zmianie branży, choć pewnie nie tylko mi. Uważam, że każdy powinien tego spróbować. Ludzie maja dość pracy za 2000zl na zlecenia.