Aktywne Wpisy
Viado +125
Serio nie ma ważniejszych tematów niż in vitro? Gospodarka upada, kryzys na granicy z ukrainą a tymczasem dla lewactwa jak zwykle najważniejsze są sprawy związane z ruchaniem
#sejm #bekazlewactwa #konfederacja #polityka
#sejm #bekazlewactwa #konfederacja #polityka
deziom +513
Rozumiem, że religijni 80 latkowie co im ksiądz #!$%@? od 60 lat co mają myśleć i ludzie z syberii mogą być przeciwko in vitro, ale że młodzi ludzie to naprawdę współczuję XD
#sejm
#sejm
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łęzifeature/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/Xz myślą o późniejszym zmergowaniu jej z
feature/X. W tym celu utworzyłem już draft pull request z
feature/Xjako base branch.
masterTeraz zauważyłem, że w
pojawiło się kilka zmian, które muszę uwzględnić w mojej gałęzi
feature/X-grad. Na ten moment widzę, że gałąź
feature/Xnie 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?
git mergeCzytałem generalnie o dwóch opcjach:
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/Xi 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
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
[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
dofeature/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 testachmam tylko trzy pytania:
1. czy po
git merge master
powinienem zrobićgit push
do remote?2.
tzn. kiedy dokładnie pracował? po tym jak zrobiłem
git checkout feature/X-grad
ale przedgit rebase feature/X
?3. Jak ktoś inny pracuje na feature/X to mogę zrobić
git cherry-pick
jest dobrą praktyką, czy raczej należy go używać sporadycznie?tak, musisz zrobić force pusha żeby zmiany się pojawiły na remote, jak będziesz chciał je zaciągnąć na feature/X-grad
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
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 czytelniejPreferuję 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ż
feature/X
pracują inne osoby, pozostaje mi w tej sytuacji tylkomerge
.@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
nafeature/X-grad
bezpośrednio zmaster
(a potem ta osoba osobno zrobimerge
zmaster
na swojej gałęzifeature/X
jak już wróci do pracy)? CzyCo 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
@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.
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
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 dofeature/X-grad
.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.
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 ->