GIT branch

0

Potrzebuje pomocy w zrozumieniu. Mam główny branch o nazwie "master". Od niego wywodzi się branch "dev". Od "dev" wywodzi się "layout", w którym będzie wiele zmian. Tworzenie nowego layoutu będzie trwało dość długo. W pewnym momencie chciałbym wypuścić kompilację (publish na azure) z docelową wersją brancha "dev", któremu zrobię merge do "master".

Moje pytanie: Co powinienem zrobić z branchem "layout", żeby w przyszłości nie było problemu z merge? Powinienem zrobić merge "dev" to "layout"?

1

Jak skończysz robotę w layout to zrób po prostu merga do dev, a potem merge z dev do master.

Możesz też okresowo sobie wrzucać dev do layout, żeby rozwiązywać ewentualne konflikty na bieżąco. Na koniec robisz merge layout do dev i git będzie już pamiętał o rozwiązanych konfliktach.

A żeby nie było konfliktów, to nie może być dwóch różnych zmian w tej samej linijce w tym samym pliku w dev i layout.

0

Dziękuję za konkretną odpowiedź. Mam jeszcze pytanie, nie wiem czy ostatnie :) Co jeżeli robię hotfix na "master"? Powinienem zrobić merge "master" to "dev", a potem "dev" to "layout"? Czy ten drugi merge jest zbędny? Wydaje mi się, że jest zbędny bo w sumie robiąc merge "master" to "dev" wynikiem jest sytuacja, w której robię po prostu commity na "dev", ale nie jestem pewien.

Wnioskuję, że aktualizacja branchy "podrzędnych" jest opcjonalna i zapobiegnie tylko sytuacji w stylu merge "dum dum" :)

0

Jak robisz brancha hotfix, który wywodzi się z master to kiedy skończysz robić hotfix robisz merge brancha hotfix do master ORAZ do dev, aby dev też jednak miał poprawkę.

Jeżeli ten hotfix nie jest potrzebny w layout to nie musisz go mergować tam. Na dobrą sprawę nie musisz też mergować dev do layout, jeżeli nie potrzebujesz tam jakichś rzeczy z dev

0

Jeżeli nie zależy mi na tych zmianach, żeby były widoczne na "dev" i "layout" to po prostu nie robię tego merge?

Na tą poprawkę nie robiłem dodatkowego brancha, ponieważ była to jedna linijka kodu. Commitowałem to bezpośrednio na "master". Teraz opcjonalnie mogę zrobić merge "master" to "dev"?

Jest jakaś różnica pomiędzy: "hotfix" to "master", "hotfix" to "dev", a "hotfix" to "master", "master" to "dev"? (Zakładając, że poprawka miała jednak osobnego brancha).

0

Tak. Musisz sobie jednak szczerze odpowiedzieć czy taki hotfix faktycznie jest zbędny w tamtych branchach. I jeżeli twój branch dev wychodzi z mastera i ma nieskończoną żywotność (tzn. robisz merge z dev do master ale dev nigdy nie jest usuwany, jest tak jakby branchem przejściowym do master) to wtedy musisz pilnować aby master był zsynchronizowany z dev. Czyli to co trafia do dev kiedyś musi skończyć w master i to co trafia do master czym prędzej powinno się znaleźć w dev.

Odnośnie ostatniego różnice są właściwie kosmetyczne. W plikach będzie to samo ale inaczej się "kulku" w gicie ułożą. Ja preferuję osobny merge hotfixa do dev i master, jakoś to czytelniej później w grafie wygląda.

0

Dzięki za wyczerpującą odpowiedź. Faktycznie brach "dev" powinien ciągnąć się w nieskończoność w naszym przypadku. Ja zawsze tworzyłem bo merge "dev" to "master" nowego "deva", ale teraz widzę, że to bez sensu.

Mam jeszcze dwie kwestie. Co się stanie jeśli zrobię merge "master" to "layout" - "dev" też zostanie automatycznie uzupełniony czy takim mergem robię błąd, bo najpierw powinienem według kolejności "master" to "dev", a potem "dev" to "layout". Jak jest w drugą stronę? Mogę od razu "layout" to "master" czy zawsze hierarchia kolejności?

0

Masz rację, nie ma sensu tworzyć za każdym razem nowego dev po merge do master, wystarczy sam merge i można dalej z devem jechać.

Jak zrobisz commita w master i zrobisz merge tylko do layout to dev tej poprawki nie będzie miał dopóki nie zrobisz merge layout do dev.

Staraj się przestrzegać hierarchii bo później powstanie Ci takie spaghetti w grafie, że połapać się w tym będzie ciężko - ale tak, będzie działać (jakoś).

Najlepiej to korzystaj z tego modelu (http://nvie.com/posts/a-successful-git-branching-model/). Jak załapiesz ten model, to praca z gitem będzie przyjemnością i wszystko będzie miało logiczny początek i koniec.. A tutaj masz rozszerzenie do gita aby łatwiej z tym pracować (http://danielkummer.github.io/git-flow-cheatsheet/index.pl_PL.html)

0

Super. Dzięki za rozjaśnienie sytuacji. Poczytam sobie o tym git-flow bo wydaje się idealne dla nas.

1

Wnioskuję, że aktualizacja branchy "podrzędnych" jest opcjonalna i zapobiegnie tylko sytuacji w stylu merge "dum dum"

Dla Gita wszystkie branche (i wszystkie remote'y) są równorzędne. To jest wyłącznie konwencja programisty (zespołu programistów) którą gałąź uważają za „główną”. Można np. pewnego dnia zmienić zdanie i uznać jakieś dev za główną gałąź, a o master zapomnieć albo go skasować - Gita to nie obchodzi, Git jest głupi. Po skasowaniu mastera dev zachowa całą swoją historię, włącznie z czasem kiedy jeszcze nie istniała jako osobna gałąź.

Ponieważ branche w Gicie są „tanie”, przyjąłem zasadę „jedna brancza - jeden ficzer”, czyli zamiast gałęzi dev na której ciągle pracuję, wolę tworzyć krótko (z założenia) żyjące gałęzie - każdą do osobnego zadania. W ramach tych gałęzi commity częste i małe. Po zakończeniu danego zadania i zmerge'owaniu do mastera gałąź jest już niepotrzebna i można ją usunąć.

Jeżeli dana gałąź żyje dłużej, to można robić okazjonalny merge z mastera do danej gałęzi - wedle gustu.

2
mlyszczek napisał(a):

Najlepiej to korzystaj z tego modelu (http://nvie.com/posts/a-successful-git-branching-model/). Jak załapiesz ten model, to praca z gitem będzie przyjemnością i wszystko będzie miało logiczny początek i koniec..

Oczywiście tylko wtedy, jeśli załapiesz i nie będziesz go używał. Bo git-flow to idiotyzm, mający na celu chyba wyłącznie utrudnić pracę z gitem i wprowadzić tam "korporacyjne standardy przemysłowe" - czyli w skrócie dodanie człowiekowi dodatkowej roboty, dzięki której czuje się potrzebny. Niekończące merdżowanie redundantnych długo żyjących gałęzi powoduje powstanie kompletnie nieczytelnej historii zmian i nie daje żadnej wartości dodatniej.

http://endoflineblog.com/gitflow-considered-harmful

0

Przecież to co koleś proponuje to nic innego jak wyrzucenie brancha master i po prostu tworzenie go i niszczenie + połączył tego mastera z branchami hotfix i release. Nie mówię, że nie ma to sensu, model wydaje się być faktycznie sensowny i prostszy od samego gitflow, ale niech koleś nie udaje, że wynalazł coś nowego, bo 90% wziął z gitflow tylko go trochę odchudził.

1 użytkowników online, w tym zalogowanych: 0, gości: 1