[grad]

Potrzebna w miarę szybka pomoc z Gita.

Mam projekt, w którym mam główny branch master i dziesiątki innych feature branchy, które są potem mergowane do mastera. Kolega pracuje nad jednym modułem, który na ten moment znajduje się w gałęzi feature/X. Ja pomagam koledze w pewnej wydzielonej części tego modułu i zacząłem pracę na gałęzi powiedzmy 'feature/X-grad, którą utworzyłem z gałęzi feature/X z myślą o późniejszym zmergowaniu jej z feature/X. W tym celu utworzyłem już draft pull request z feature/X jako base branch.

Teraz zauważyłem, że w master pojawiło się kilka zmian, które muszę uwzględnić w mojej gałęzi feature/X-grad. Na ten moment widzę, że gałąź feature/X nie ma jeszcze tych zmian (jest kilkanaście commitów za masterem). Jaki jest właściwy sposób uwzględnienia zmian z mastera w mojej gałęzi feature/X-grad?

Czytałem generalnie o dwóch opcjach: git merge i git rebase. W tym momencie mój pull request zawiera tylko te zmiany, które ja sam wprowadziłem do swojej gałęzi w porównaniu z feature/X i przez to jest w 100% czytelny. Czy jak użyję git merge` to wtedy dojdą mi do tego zmiany z mastera i PR stanie się dużo mniej czytelny?

#programowanie #git

[Prism2772]

@grad: Rebase zachowa historię commitów, o ile dobrze rozumiem Twój problem

[oxern]

git checkout master -> git pull -> git checkout feature/X -> git merge master -> git checkout feature/X-grad -> git rebase feature/X // no i po drodze będziesz musiał usunać konflikty jak się jakieś pojawią

jeżeli ktoś już wcześniej pracował na feature/X po tym jak z niej wyszedłeś to nie rób git rebase bo możesz stracić kod

[grad]

@Prism2772: Postarałem się mniej więcej rozrysować uproszczoną historię jak to wygląda teraz:

[master]....................A -> B -> C -> D -> F -> M
[feature/X].........................\ -> E -> G -> K -> L
[feature/X-grad]................................\ -> H -> I

W tym momencie utworzyłem PR, aby zmergować feature/X-grad do feature/X i widzę w szczegółach PR moje dwa commity H i I. Niestety nie mogę teraz zmergować tych dwóch gałęzi bo mam błąd w testach

[oxern]

@grad: możesz też wrzucić do siebie do PR commit, który naprawia poprzez git cherry-pick 98vcx7436 <--- numer commita M // nie zapomnij zrobić git pull jak będziesz się checkoutował na kolejne branche przed mergowaniem

[grad]

@oxern: dzięki! ma to sens

mam tylko trzy pytania:
1. czy po git merge master powinienem zrobić git push do remote?
2.

jeżeli ktoś już wcześniej pracował na feature/X po tym jak z niej wyszedłeś to nie rób git rebase bo możesz stracić kod

tzn. kiedy dokładnie pracował? po tym jak zrobiłem git checkout feature/X-grad ale przed git rebase feature/X?
3. Jak ktoś inny pracuje na feature/X to mogę zrobić

[grad]

@oxern: To brzmi trochę jak rozwiązanie mojego problemu. Czy git cherry-pick jest dobrą praktyką, czy raczej należy go używać sporadycznie?

[oxern]

@grad: > 1. czy po git merge master powinienem zrobić git push do remote?
tak, musisz zrobić force pusha żeby zmiany się pojawiły na remote, jak będziesz chciał je zaciągnąć na feature/X-grad

Czy git cherry-pick jest dobrą praktyką

chyba najmniej inwazyjną w tym przypadku jeżeli potrzebujesz tylko jeden commit u siebie, który coś naprawia. Git rebase to nic innego jak wykonanie kilkukrotne komendy git cherry-pick

[grad]

@oxern: wielkie dzięki za pomoc, popróbuję sobie na przykładzie i powinno się udać

[oxern]

@grad spoko, daj znać czy pomogło

[grad]

@oxern: pomogło, w końcu zdecydowałem się na pierwszą opcję, tj. z git merge. Nie miałem pewności czy tej jeden commit na masterze nie ma żadnych zależności i uznałem, że tak będzie czytelniej

[danzaxkuduro]

@grad: Miło patrzec jak ktos komus pomaga na wykopie bez zbednego #!$%@? cos cudownego XD

[MacDada]

@grad: Nie lubię merge'ów, bo nie idzie potem wykumać historii commitów i zmian, które "po sobie" następują (taka ma być idea, odzwierciedlać realną historię, a nie wyidelizowaną "poukładaną").

Preferuję zawsze rebase, który nieco historię "zakłamuje", ale jest dużo czytelniejszy i jasne jest co z czego wynika.

"Jedyny' problem z rebase jest taki, że nie zawsze można go zrobić – rebase przepisuje historię, więc NIGDY TEGO NIE RÓB z commitami, które już

[grad]

@MacDada: dzięki za poradę! załapałem ideę, ale przez to, że nad feature/X pracują inne osoby, pozostaje mi w tej sytuacji tylko merge.

@MacDada @oxern: Jeszcze jedno szybkie pytanie: jeśli nad feature/X pracują inna osoba i powiedzmy aktualnie nie jest dostępna, to czy mogę zrobić merge na feature/X-grad bezpośrednio z master (a potem ta osoba osobno zrobi merge z master na swojej gałęzi feature/X jak już wróci do pracy)? Czy

[MacDada]

@grad: Rozbiega się o historię – tej „wspólnej” nie ruszaj, bo później może być ciężko odkręcić.

Co to znaczy wspólnej: takiej którą ktoś może mieć.

Zapomnijmy o branchach – dajmy na to, że jest tylko prosta historia commitów. Jak pracujesz sam z repo, to możesz skasować 10 ostatnich commitów lokalnie i dołożyć 2 nowe. Jak spróbujesz to wysłać pushem to będzie git poinformuje, że lokalnie brakuje Ci tych 10 commitów z

[MacDada]

czy mogę zrobić merge bezpośrednio z master

@grad: w skrócie: merge możesz zrobić zawsze „bezpiecznie”. to rebase jest potencjalnie niebezpieczny, bo rebase przepisuje historię. ale jak już skumasz rebase, to jest to fajna opcja. w zależności od sytuacji jedno i drugie jest przydatnym narzędziem.

[grad]

@MacDada: Super czytelnie wyjaśnione, serio. Na razie rebase zostawię w spokoju (pozostawię sobie weekend na naukę) i będę kontynuował z bezpieczniejszym git merge. Tylko tym razem rozchodzi się mi o to, czy w moim przypadku (opisanym we wpisie i moim pierwszym komentarzu) mogę zrobić git merge na feature/X-grad bezpośrednio z master, czy powinienem przejsć przez tą ścieżkę co opisał @oxern, czyli:

git checkout master -> git pull -> git

[MacDada]

@grad: możesz i tak i tak „bezpiecznie” – bo to merge. pozostaje pytanie co lepsze.

jeśli nie masz zamiaru pushować swojego lokalnego brancha feature/X do remote, to nie merge'uj do niego mastera. bo po co. tylko się historia gmatwa. merge'uj master bezpośrednio do feature/X-grad.

[MacDada]

@grad: Generalnie jestem zdania, że najlepiej jak każdy ma swoje feature branche, które synchronizuje z masterem i tyle.

Robienie branchy od branchy niepotrzebnie komplikuje interes.

Należy taski dzielić na małe, branche robić małe i „krótkożyjące”. Wtedy nie ma bałaganu i kombinowania z synchronizowaniem wszystkiego.

[grad]

@MacDada: Też jestem takiego zdania. To był trochę wyjątek, gdzie sam feature/X okazał się dość duży.

Ok, to zrobiłem test na testowym repo:
- git checkout master -> git pull master -> git checkout feature/X-grad -> git merge master -> git push (w PR na githubie widzę dodatkowo wszystkie zmiany z mastera jako część mojego PR)
- (to musi zrobić kolega jak wróci) git checkout master -> git pull master ->