GIT - jakie branche w wytwarzaniu oprogramowania

Cześć,

W zespole chcemy przesiąść się na GIT. Pomysł branchy jest następujący:

1. master -> czyli kod, który działa produkcyjnie
2. development -> czyli kod, który działa na środowisku testowym

W zespole jest trzech programistów. Załóżmy, że każdy pracuje nad inną funkcjonalnością, więc tworzy sobie nowy branch (np feature-1).

Pytania:

1. Branche feature powinny bc tworzone na podstawie master czy development? Wydaje mi się, że master

2. Jeśli na test czyli branch development wejdzie kilka zmian (kilka branchy feature), ale na produkcję będziemy chcieli wrzucić tylko wybrane to powinniśmy mergować feature bezpośrednio do master?

Cześć,

Sądzę, że ten artykuł rozwiążę wasze wątpliwości https://www.atlassian.com/git/tutorials/comparing-workflows

1. Ja w swojej pracy robię nowe gałęzie featureowe z dev'a. Mastera traktuje jako gałąź do której tylko i wyłącznie merguje dev'a.
2. Mergowanie feature'a bezpośrednio do mastera z pomięciem dev'a to tak trochę średnio. Imho najlepszym rozwiązaniem jest stworzenie gałęzi integrującej przed wypuszczeniem nowej wersji

W firmie, w ktorej obecnie pracuje, mamy ciekawy proces. Uzywamy GITa i Gerrita.

Wszyscy pracuja tylko i wylacznie na master, jak zmiana jest gotowa wypychamy ja do gerrita, gdzie pod code review jest mergowana do origin/master.
Jesli nie przechodzi code review robimy checkout, fix i git --amend.

Jesli mamy spory stack commitow a chcemy tylko nie ktore wypchnac do gerrita, wtedy do dziela wkracza git rebase, przestawienie szyku itd.
Bardzo dobrze sie to sprawdza, nie ma balaganu z branchami, masy commitow do jednego ticketa, etc.

Obczaj sobie ten model pracy projektowej z Gitem. Korzystam z niego cały czas i bardzo sobie chwalę :)

http://nvie.com/posts/a-successful-git-branching-model/

Ja nie ogarniam tego rozróżniania na master i development, zwłaszcza w Git-Flow. Skoro i tak każdy commit na masterze ma tag z wersją, to czemu nie połączyć mastera i development i zostawić tagi jak są? Jak dla mnie master jest wersją działającą na stagingu (obecnie rozwijaną), a tagi oznaczają wersje, które wylądowały na produkcji. Zdecydowanie mniej merge, nie ma dylematu, z której gałęzi tworzyć nowe gałęzie developerskie.

@hauleth: chodzi pewnie o to że master i develop mają różne zestawy poprawek i zdarzają się hotfixy które musisz zrobić na już na wersji takiej jak na prod, a na develop one mogą wejść albo nie (bo np. są tak słabo napisane że lepiej je od razu zrefaktorować, albo już to jest naprawione na dev i nie trzeba nic migrować).

Wersja z tagami to musisz czekać na release z dev? Jak masz release raz dziennie to nie ma problemu, ale jak masz czekać kwartał (a tak bywa) to trochę słabo.

@hauleth: plus zauważ, że jak masz rozdzielone na master i develop to możesz zrobić coś w stylu "pseudo-scentralizowanego" systemu kontroli wersji (jak np. SVN). Mając dwa branche, masz kontrolę nad tym co się dzieje. Bo jak robisz jakieś zmiany (nowy feature, nowy layout) to najpierw testujesz na developie i jak nic się nie wywala to wrzucasz na produkcję (ewentualnie później robisz hotfixy).

@vpiotr: ale w czym problem ze zrobieniem hotfixa?

$ git checkout -b hotfix v1.0.0
$ # edit
$ git tag -s v1.1.0
$ git push --tags
$ git checkout master
$ git merge --no-ff hotfix

I masz gotowe. Flow nie różni się niemal niczym od posiadania osobnej gałęzi na produkcję.

Wersja z tagami to musisz czekać na release z dev? Jak masz release raz dziennie to nie ma problemu, ale jak masz czekać kwartał (a tak bywa) to trochę słabo.

Nie za bardzo ogarniam o co Ci chodzi? Masz tag v1.0.0 i masz commit deadbeef, który ma wylądować na produkcji. Robisz więc git tag -s v2.0.0 deadbeef i masz nową wersję. Nikt nie musi na nic czekać, nie ważne czy robisz 1 deploy dziennie czy na rok.

plus zauważ, że jak masz rozdzielone na master i develop to możesz zrobić coś w stylu "pseudo-scentralizowanego" systemu kontroli wersji

To po co używać Gita? Dla tego, że popularny? Poza tym posiadanie 2 gałęzi ma się nijak do rozproszenia/centralizacji.

Bo jak robisz jakieś zmiany (nowy feature, nowy layout) to najpierw testujesz na developie i jak nic się nie wywala to wrzucasz na produkcję (ewentualnie później robisz hotfixy).

Ale czym się to różni od tagów? Na produkcji ląduje to co zostało otagowane, nie gałąź. Nie widzę najmniejszej różnicy.

EDIT: I nie, nie testujesz na developie, tylko testujesz w feature branchu. Jak przeszło testy wtedy, ląduje na masterze, tam przechodzi kolejne testy po deploymencie na staging, i jak to przeszło, to tagujesz commit i masz deploy na produkcję.

@hauleth: chyba czegoś nie rozumiem. Nawet jeśli przetestuję swoje zmiany (commit) w pełni, to przecież nie mogę odpowiadać za innych (i zatagować / wrzucić na prod ich zmiany).
Wygląda to na schemat z jednym programistą, ale pewnie coś nie zrozumiałem.

Paczaczaj:

Małe litery, czyjeś zmiany, duże litery, twoje zmiany

a
| \
b C
| /
C'
|
d

Jeśli masz pewność, po merge, że Twoje zmiany C' są ok i działają, to co to za różnica, czy zrobisz taga tutaj, czy zrobisz merge do niepotrzebnej gałęzi i zrobisz taga tam? Przecież ten tag będzie miał dokładnie taką samą zawartość i nie będzie się niczym różnił. Nie musisz ufać innym developerom. Dodatkowo to nie ty masz tagować, tylko ktoś kto robi review aplikacji i akceptuje zmiany na produkcję lub nie. Nikt nie mówi, że masz zawsze tagować HEAD, wręcz przeciwnie, tagujesz dokładnie ten commit, który ma wylądować na produkcji, kiedy wszystko jest gotowe.

mi sie wydaje ze develop to byt nadmiarowy. gerrit i jazda

Jeśli ma być efektywnie, to: master i feature branche, feature jest testowany i mergowany do mastera, a potem idzie na produkcję. Hotfixy tak samo.

Jeśli ma być korporacyjna kupa to git flow albo tylko jedna gałąż albo w ogóle najlepiej zawsze tylko amendować ostatni commit. Historia jest wtedy czysta i nie ma problemu z gałęziami.

Polecam prostotę. master. jak dobrze działa CI to w większości projektów nie ma po co się bawić w feature branche.
Jak robicie coś większego to feature toggle > feature branch. Z wyjątkiem refaktoringów oczywiście.
Z drugiej strony lubię pracować na sforkowanym repo (tak jak na githubie) - w zasadzie to działa jak branch, ale nie muszę wymyślać ciągle nazw dla branchów... a jednocześnie mam gdzie bezpiecznie pushować. (to jest taki personal/private branch).

Co do develop - ma sens jak robicie bibliotekę. Wtedy develop to wersja rozwojowa, a master referencyjna/produkcja, gdzie ludzie np. bug i pulle raportują.
W normalnym projekcie - niepotrzebne zamieszanie.

Co do używania GITa i branchy - to ja uważam to własnie za tzw. "paradox gita".: tak łatwo się merguje, rebasuje..., że w zasadzie nie ma już tak częstej potrzeby robienia branchów.

Polecam prostotę. master. jak dobrze działa CI to w większości projektów nie ma po co się bawić w feature branche.

Właśnie jak CI dobrze działa to feature branche to manna z nieba. Rozwijasz w izolacji funkcjonalnośc i wiesz, że ona sama w sobie działa. Dodatkowo nie wypchniesz do mastera przypadkowo zmian, które się nie budują.

Co do develop - ma sens jak robicie bibliotekę. Wtedy develop to wersja rozwojowa, a master referencyjna/produkcja, gdzie ludzie np. bug i pulle raportują.

Dalej nie. Jak masz bibliotekę, to tym bardziej rozwój na masterze oraz tagi do oznaczania wersji. Przejrzyj sobie GH i zobacz, że praktycznie każdy projekt tak robi, bo signed tag na GH jest jednocześnie release, do którego możesz dodać np. skompilowane binarki.

Co do używania GITa i branchy - to ja uważam to własnie za tzw. "paradox gita".: tak łatwo się merguje, rebasuje..., że w zasadzie nie ma już tak częstej potrzeby robienia branchów.

IMHO wręcz przeciwnie. Dzięki temu, że się to robi tak łatwo, to się robi to jak najczęściej. Do momentu kiedy twoje PRki mają własne PRki.

hauleth napisał(a):

Właśnie jak CI dobrze działa to feature branche to manna z nieba. Rozwijasz w izolacji funkcjonalnośc i wiesz, że ona sama w sobie działa. Dodatkowo nie wypchniesz do mastera przypadkowo zmian, które się nie budują.

I co się wtedy strasznego stanie? No co się stanie?

O tym dlaczego przeważnie feature branche są do bani opowiada na początku tej (świetnej ) prezentacji Neal Ford

https://vimeo.com/110776191

Nie lubie feature branchy bo, albo są krótkie (kilkugodzinne) i jest ich dużo. Wtedy wkurza nazywanie i gubienie się w nich. Ja się gubię. Biurokracja.
Albo jest mało i długich, a wtedy jest pełna katastrofa gwarantowana.

Co do develop - ma sens jak robicie bibliotekę. Wtedy develop to wersja rozwojowa, a master referencyjna/produkcja, gdzie ludzie np. bug i pulle raportują.

Dalej nie. Jak masz bibliotekę, to tym bardziej rozwój na masterze oraz tagi do oznaczania wersji. Przejrzyj sobie GH i zobacz, że praktycznie każdy projekt tak robi, bo signed tag na GH jest jednocześnie release, do którego możesz dodać np. skompilowane binarki.

Tak. Większośc na Githubie tak ma. Ale ten develop/master też występuje. Sam wcale nie lubię zabawy w develop / master. Ale dokładnie w bibliotekach (projektach typu "commmon") takie podejście mi się sprawdziło (przy czym nie ja ten develop/master wymyślałem - mnie wkurzał początkowo).

jarekr000000 napisał(a):

Nie lubie feature branchy bo, albo są krótkie (kilkugodzinne) i jest ich dużo. Wtedy wkurza nazywanie i gubienie się w nich. Ja się gubię.

Bo trzeba je od czasu do czasu czyścić. Co już dawno zmergowane do mastera, to do wywalenia. Commity i tak zostaną w historii, a nazwa brancha nie jest już potrzebna.

O tym dlaczego przeważnie feature branche są do bani opowiada na początku tej (świetnej ) prezentacji Neal Ford

https://vimeo.com/110776191

Tyle, że jego przykład dotyczy raczej rozwiązania takiego jak SVN (co z resztą sam wspomina), gdzie branch jest ciężki, jego merge jest też upierdliwy, a dodatkowo tracisz historię pracy. Git działa zgoła inaczej i łatwo można tego typu problemów uniknąć:

• rebase na origin/master zamiast merge
• gałęzie powinny żyć krótko: małe, inkrementacyjne zmiany, zamiast przepisywania całego projektu na nowo
• CI buduje nie tylko mastera, ale każdy feature branch też, co więcej, możliwość merge powinna być zablokowana dopóki nie przejdą testy i nie będzie review

Gicie, gdzie merge jest niczym więcej jak commitem z 2+ rodzicami, a sama gałąź to tylko label dla commita, takie rozwiązanie ma bardzo dużo sensu.

Wszystko zależy od konkretnego przypadku.
Jeżeli masz 2. programistów i projekt to odpowiedni model będzie zupełnie inny niż w przypadku kiedy programistów masz wielu, a zamiast projektu masz produkt, który pewnymi częściami się różni pomiędzy klientami.
(Wiem, że zaraz ktos powie, że powinny być wtedy osobne repa, ale to też nie zawsze jest najlepszy pomysł).

Podobnie sytuacja się ma w przypadku porównania repozytoriów monolitów i mikroserwisów(to, że teraz jest moda, nie znaczy, że to jest najlepsze rozwiązanie).

Gerrit to faktycznie fajne narzędzie, szczególnie jak się podpnie odpowiednio ustawionego Sonara i Jenkinsa pod review, ale czy zawsze to będzie najlepszy wybór?

silver bulet NIE istnieje

Nie piszę oczywiście żeby wszystko wymyślać samemu przy każdym projekcie, ale projekt przecież żyje, więc wystarczy się nie zabetonować w przyjetym na początku podejściu i po jakimś czasie proces się poprawi.
Jeżeli używacie zwinnych metodologii, to po to właśnie macie retro.
Nie o to chodzi żeby wybrać optymalny model, tylko o to żeby wybrać model wystarczająco dobry.

To rozwiązanie z jednym masterem nie ma za bardzo sensu jak macie na prodzie wiele wersji softu (np klient się nie przepiął z poprzedniej ale ma z nami SLA na klika milionów więc trzeba backportować bugfixy). Wtedy tak czy siak dostaniecie releasowe branche czy tego chcecie czy nie. To jest mniej problem webappek ale bardziej problem z poziomu serwisów, zwłaszcza korpo. Podobnie nie wiem jak z jednym masterem puszczacie testy, załóżmy że w repo jednego serwisu macie zmiany z dwóch historyjek, z czego obydwie np zmieniają interface (powiedzmy wystawiają więcej danych albo biorą więcej z requestu) i jedna z nich jest zrypana - co ma zrobić taki biedny QA który dostaje waszą historyjkę do testów? Wydłubywać te commity które nie są z jego historyjki? Jak są branche to sobie zdeployuje instancję serwisu z tym co on ma testować i da wam feedback który nie ma błędów innej osoby. Problem się pojawi przy mergowaniu tego, ale przynajmniej wiadomo że przed zmergowaniem coś działało i ewentualny błąd wynika z rozwiązania konfliktów.

@Wesoły Kaczor deployujesz branche https://docs.gitlab.com/ee/ci/autodeploy/index.html. Przy czym patrz, że ja nie mówię, że branch per wersja jest zły, ale, że posiadanie osobnej gałęzi do developmentu i osobnego mastera, w którym każdy commit jest jednocześnie otagowany. Ja rozumiem, że mogą być różne problemy wymagające różnego podejścia, ale to jest ta rzecz, która mnie boli najbardziej.

Git (nie „GIT” - to jest słowo a nie skrót) to jest naprawdę coś jakościowo innego niż Subversion i „przechodzenie na Gita” tylko po to by udawać pod nim SVN-a to niepotrzebne komplikowanie sobie życia.

Brancha „per wersja” ma sens. W ramach tej branchy można tagować release'y, podwersje, hotfixy itp.
Brancha „do developmentu” nie ma sensu. Powinien być nią po prostu master.

Commity raczej nie powinny być wrzucane bezpośrednio do mastera, tylko do tymczasowych „ficzer branczy” (brancza per task), które po zmerdżowaniu do mastera są do usunięcia.

Ja oraz 3-4 innych starszych programistów zajmujemy się utrzymaniem bajzlu z branchami. Czasem nawet pół dnia mi schodzi na to.
My mamy branche: mastera(u nas akurat to pełni rolę developa), release(kilka, bo utrzymujemy 3-4 wersje wstecz) oraz feature branche (zmiany i tickety) oraz branche klientów(do oznaczania którą wersję ma klient w zasadzie to wystarczyły by tagi). Dodatkowo pracujemy na forkach.

Wszystko to ma sens gdy pracujesz w większej grupie, nad dwoma projektami rozwojowymi i jeszcze 2-3 osoby zrobią tickety zgłoszeniowe na kilkudziesięciu klientów (choć tylko kilkunastu coś zgłasza). Wtedy ktoś musi czuwać żeby to spinać.

Branche master, release i feature branche są potrzebne żeby wydać wersję dla klienta tylko z tym co ma dla niego iść - coś zgłosił, robimy to, testujemy, i działa, ale inne modyfikacje i poprawki dla innych klientów mogą coś schrzanić - trzeba gdzieś przetrzymać nie do końca przetestowane commity.

Sposób podziału repo gita to jedno, ale jeszcze jest kwestia podziału zadań.

Jeżeli zadania będą długie, zespół spory, a aplikacja nie za duża, to większość życia będzie się spędzać na rozwiązywaniu konfliktów.
Jeżeli przypadek będzie taki sam, ale taski będą podzielone na małe, szybkie subtaski to nagle okaże się, że konfliktów prawie nie ma, ale za to więcej czasu spędzi się na jira.

Jeszcze inną kwestią jest sam zespół bo jeżeli rotacja jest spora, to skomplikowane/złożone modele repozytoriów mogą powodować narzut na wdrożenie się w nie.

Zawsze jest coś za coś, więc nie wysatrczy znać rozwiązań na pamięć, tylko trzeba rozumieć konsekwencje i balansować w celu minimalizacji problemów.
Podejścia typu: "X albo śmierć", gdzie X to nazwa jakiegoś modelu pracy z gitem, czy ogólniej dowolnej metodologi/frameworku/etc pokazuje tylko, że ktoś nie ma jeszcze wystarczająco dużo doświadczenia do podejmowania takich decyzji.