Praca z GIT - merge

Takie techniczne dość pytanie mam do doświadczonych programistów z GITem.
Jeśli tworzymy sobie swój własny branch na nową funkcjonalność, po czym zatrzymamy ten rozwój, zmieniamy w tym czasie wiele (mergując inne branche na masterze) i powrócimy do wcześniej wspomnianego, wstrzymanego brancha to aby mieć najświeższy stan na swoim branchu mergując go z tym co jest na masterze popełniamy błąd? Czy powinniśmy jednak pracować ze stanem na masterze z okresu rozpoczęcia pracy nad nową funkcjonalnością (utworzenie branch), a dopiero potem łączyć wszystkie zmiany? Mi wydawało się dość wygodne, by zaciągać do swojego brancha zmiany z master i dopiero potem je zmergować jak zakończę pracę w tym swoim branchu. Jak najlepiej więc pracować w takim przypadku?

IMO najwygodniejszy w takiej sytuacji jest rebase; staram się unikać mergów, które nie są fast-forward (ponieważ komplikują historię).

IMO najlepiej jeśli branch jest x commitów za masterem, to zrobić rebase tego brancha. Wtedy wskaźnik brancha się przesuwa do aktualnego mastera, rozwiązujemy konflikty lub nie i albo możemy to zmergować albo pracować sobie dalej na branchu z tym, że z aktualnymi źródłami.

EDIT:
Ahh 17 sekund szybszy :D

Dziękuję, myślę że to będzie dla mnie pomocne.

Ja jak pracuję długo nad jakimś ficzerem, to też zaciągam zmiany z mastera w miarę na bieżąco. Prościej rozwiązywać mało konfliktów na raz, niż potem dużo przy wielkim merge ficzera do mastera.
Rebase jest w ogóle nieprzydatny do pracy na poziomie master <-> ficzer i ma sens jedynie na lokalnych gałęziach.

ponieważ komplikują historię

A na co komu liniowa historia?

rebase'ami tylko denerwujemy innych którzy chcą coś zrobić lub choćby zobaczyć na tej samej branczy.
a jeszcze gorzej gdy ktoś od takiej odbije swoją…

A na co komu liniowa historia?

Aby odpowiedzieć na to pytanie, powinniśmy najpierw zadać inne: dla kogo przeznaczona jest historia systemu kontroli wersji?

W moim przypadku odpowiedź brzmi dla innych ludzi, stąd przed ostatecznym mergem wykonuję rebase, fixup oraz inne porządkujące czynności :-)

a jeszcze gorzej gdy ktoś od takiej odbije swoją…

Jeśli wszyscy są świadomi tego, że drużyna wykorzystuje rebase, nie stanowi to żadnej przeszkody.

Reabse wolo robić tylko jeśli wybrany branch jest tylko mój.
Jeśli ktoś inny też używa tego brancha to trzeba się z nim dogadać, albo robić zwykły merge.

Ja lubię rebase i/albo squash bo: rozumiem co się dzieje i nie cierpię szerokiej historii. Nie zmuszam nikogo do tej praktyki. Ważniejsze, żeby osoba robiąca merge, wiedziała co robi i czuła się pewnie.
Dlatego ja ci mówię rób tak jak umiesz. Nie ważne jak dostarczysz kod, ważne, żeby poprawnie działało i spełniało wszystkie wymagania projektu (te biznesowe jak i coding convention). Jak nabierzesz większej wprawy to przyjdzie czas korzystania z bardziej zakręconych funkcji git-a.

Jeśli kod jest pisany z głową i z przestrzeganiem Single Responsibility Principle to konflikty są ma małe i proste w naprawieniu.
Niestety dla większości SRP to tylko fajne pytanie podczas rekrutacji.

Patryk27 napisał(a):

W moim przypadku odpowiedź brzmi dla innych ludzi, stąd przed ostatecznym mergem wykonuję rebase, fixup oraz inne porządkujące czynności :-)

Tylko po co, skoro prościej i szybciej można zrobić merge ze squashem?
A rebase z zostawieniem historii swoich śmieciowych lokalnych commitów w masterze, to jest zbrodnia na czytelności.

skoro prościej i szybciej można zrobić merge ze squashem?

Zależy - nie zawsze chcesz / chcę wrzucić branch tak, jak gdyby był jednym, całym commitem.

A rebase z zostawieniem historii swoich śmieciowych lokalnych commitów w masterze, to jest zbrodnia na czytelności.

Ano, nie zaprzeczam.

Patryk27 napisał(a):

Zależy - nie zawsze chcesz / chcę wrzucić branch tak, jak gdyby był jednym, całym commitem.

No może Ty nie zawsze. Bo ja zawsze, dla mnie jeden task = jeden wpis w historii.

somekind napisał(a):

Patryk27 napisał(a):

Zależy - nie zawsze chcesz / chcę wrzucić branch tak, jak gdyby był jednym, całym commitem.

No może Ty nie zawsze. Bo ja zawsze, dla mnie jeden task = jeden wpis w historii.

Commity robię małe. Jedno, kilkulinijkowe. Nie wyobrażam sobie żebym miał tyle tasków.
Ani wielkich commitozaurów na tysiąc linii które robią zylion rzeczy na raz.

Bo ja zawsze, dla mnie jeden task = jeden wpis w historii.

Przy okazji robienia zadań staram się porządkować ruszane przeze mnie pliki - wszystkie takie refactoring-like zmiany idą do osobnego commitu, aby nie stwarzały szumu w trakcie CR. Plus pojedynczy mały commit łatwiej jest cofnąć niż taki ogromny.

Choć zależy to ofc. od drużyny - mi pasuje taki flow, komuś innemu inny, a ktoś inny jeszcze zasugeruje trunk-based development.

Azarien napisał(a):

Commity robię małe. Jedno, kilkulinijkowe. Nie wyobrażam sobie żebym miał tyle tasków.

Ja robię nawet półlinijkowe. Na swoim feature-branchu oczywiście. Bo wbijanie tych dziesiątek commitów do mastera nie ma najmniejszego sensu, dlatego robię merge ze squashem i w masterze jeden task to jeden commit.

Patryk27 napisał(a):

Przy okazji robienia zadań staram się porządkować ruszane przeze mnie pliki - wszystkie takie refactoring-like zmiany idą do osobnego commitu, aby nie stwarzały szumu w trakcie CR. Plus pojedynczy mały commit łatwiej jest cofnąć niż taki ogromny.

Tu jakby nie widzę sprzeczności, po prostu refactoring to powinien być oddzielny task.

Commity robię małe. Jedno, kilkulinijkowe. Nie wyobrażam sobie żebym miał tyle tasków.

Ja robię nawet półlinijkowe. Na swoim feature-branchu oczywiście. Bo wbijanie tych dziesiątek commitów do mastera nie ma najmniejszego sensu

Nigdzie nie mówiłem o masterze. Na braczę ficzerową, nad którą zwykle pracuje kilka osób, więc małe i częste commity sprzyjają współpracy.

Kiedyś potem jest robiony merge do mastera i nikogo nie obchodzi czy to jest 1 commit czy 200.

Azarien napisał(a):

Nigdzie nie mówiłem o masterze.

Ale ja mówiłem. Więc jeśli Ty w odpowiedzi na to, co ja mówię, zaczynasz mówić o czymś innym, to nie widzę w tym zbyt wiele sensu.

Kiedyś potem jest robiony merge do mastera i nikogo nie obchodzi czy to jest 1 commit czy 200.

No ok, u Was się tak pracuje. Ja pracuje z ludźmi, którzy nie lubią bałaganu, ja też nie, więc w masterze staramy się mieć jeden commit per task. Nikomu historia pracy nad konkretnym taskiem nie jest potrzebna po jego ukończeniu.

rebase'ami tylko denerwujemy innych którzy chcą coś zrobić lub choćby zobaczyć na tej samej branczy.
a jeszcze gorzej gdy ktoś od takiej odbije swoją…

Jak masz 80 commitów na branchu to też?

Warto jeszcze używać tej opcji przy pracy lokalnej https://git-scm.com/docs/git-rerere zwłaszcza jak się robi dużo commitów