Wątek przeniesiony 2020-05-04 22:01 z Off-Topic przez cerrato.

Git - jak pracujecie?

0

Witam serdecznie,
Chciałem się poradzić, w jaki sposób pracujecie na gicie?
Zakładam że Master = wersja produkcyjna
Dev = wersja robocza.

Załóżmy że mamy do wykonania funkcjonalność:

  • formularz logowania,
  • mapa strony,
  • formularz rejestracji,
  • podgląd użytkownika.

Jak byście commitowali swoją pracę? 1 commit = 1 wykonany moduł?

Czy jakoś inaczej? :)

5

master - wersja robocza i tagi jako wersje produkcyjne. Branch to jakaś działająca część funkcjonalności. Może być nawet nieaktywna jeszcze w produkcie, ważne że da się przetestować (automatyczne albo manualnie zależnie od funkcjonalności). Czasami chowanie za flagą, którą można włączyć w ustawieniach do debugowania. Zazwyczaj branch jest squashowany do 1 commita przy mergu.

1

W moich side projektach:

  • master to obecna wersja stagingowa
  • tagi to wersje produkcyjnne
  • branche - nowe funkcjonalności/fixy

Co do podanego przykładu przez Ciebie, to zależy, ale często część z tego wyląduje w Initial commit.

1

Gdybym prowadził projekt to nie miałbym mastera tylko tagi + develop

Ile osób pracuje nad aplikacja?
1 -> wrzucasz wszystko na developa. Jeśli zadania są małe to może być 1 commit 1 moduł.
2-6 -> pewnie najprościej byłoby podzielić zadania na te związane z inżynierią i te stricte biznesowe. Każdy dostaje swój moduł i realizuje je w postaci feature_branchy. Przez taski developerskie rozumiem np skonfigurowanie bazy danych, pobierania danych z internetu, ustalenie jakiegoś flow do tłumaczeń czy dostarczenia grafik od designera.
7 - 20+ -> tak samo jak w drugim punkcie tylko każdy moduł to osobny team z tymi samymi problemami. Potem trzeba zrobić committee żeby ludzie się dogadali czy tabulatory czy spacje.

1

Ja polecam GitFlow:

gitflow
https://datasift.github.io/gitflow/IntroducingGitFlow.html

Są oczywiście różne zdania na jego temat, ale ja zazwyczaj spotykam się z pozytywnymi no i z doświadczenia mogę powiedzieć, że znacznie ułatwia pracę w robocie. Wiadomo, że ciężko jest czasami w firmie wprowadzić go dokładnie, jak w opisach, ale u nas w jakichś 90% się udało i bardzo spoko się z nim pracuje.

0

Możesz napisać z jakimi problemami nie spotykacie się dzięki git flow?

1
lukmopy napisał(a):

Jak byście commitowali swoją pracę? 1 commit = 1 wykonany moduł?

Twój roboczy branch więc commit według twojego uznania, że "coś konkretnego, określonego" zrobiłeś. Samo pojęcie "coś" trudno jednoznacznie zdefiniować.
Commit to twój backup, dupochron, historia "myślenia" nad zmianami, punkt do wycofania się ze ślepej uliczki.
O właśnie, chyba opis commit to coś nad czym warto poświęcić chwilę zastanowienia. Jest sensowny message, to znaczy że nowy commit sam się prosi o zrobienie. Nie wiesz jak sensownie opisać commit, to chyba nie pora na "prywatny" commit.

Co już upubliczniasz, to inna sprawa. Jaki "flow" macie ustalony tak robisz. Szkoda pisać jaki, bo zaraz będzie dyskusja o wyższości świąt i "naszego" rozwiązania, a po drugie albo "maszeruj (i się dostosuj do ustawień firmy) albo giń". ;) .

0
Michał Sikora napisał(a):

Możesz napisać z jakimi problemami nie spotykacie się dzięki git flow?

Jasne, tu masz kilka na szybko:

  • oporności przy tworzeniu ficzerów, ogarnianiu releasów czy wypuszczaniu hotfixów,
  • nie ma branchowego chaosu - nawet jak jest sporo branchy, to jest je łatwo ogarnąć z GitFlowem i łatwo między nimi przechodzić,
  • nie ma bałaganu w repo i procesach - bo są ogarnięte i uporządkowane (ideałów nie ma, ale jest serio okej),
  • nieogar kilku wersji - z Gitflowem możesz wspierać stare wersje i kodzić nowe (więc ogarnianie kilka wersji apki nie jest bolesne).

No i dla mnie jeden z ważniejszych punktów, to master = produkcja. Boleśnie dowiedziałem się kiedyś, jak bardzo jest to potrzebne. :D

0

Jak byście commitowali swoją pracę?

Jeśli pracujesz w zespole, to najlepiej uzgodnić z zespołem (jeśli chodzi o te "wypychane" commity, bo roboczo to możesz sobie robić jak chcesz).

Natomiast jak robisz projekt samodzielnie, to uzgadniasz sam ze sobą, czyli robisz tak, jak ci wygodnie.

Załóżmy że mamy do wykonania funkcjonalność:

formularz logowania,
mapa strony,
formularz rejestracji,
podgląd użytkownika.
Jak byście commitowali swoją pracę? 1 commit = 1 wykonany moduł?

To zależy. Niektóre moduły będą o siebie zahaczać.

Przykładowo:
formularz logowania i rejestracji będzie pewnie korzystał z tych samych styli czy komponentów, więc równie dobrze można by zrobić commit "shared code for forms" albo jakkolwiek to nazwiesz, potem zrobić commit dla formularza logowania, potem dla rejestracji, potem zrobić commit dla podglądu użytkownika, potem ci się coś przypomni i zrobić dodatkowy commit, który zmienia coś w którymś z formularzu, potem mapę strony, potem jakiś commit refaktorujący jedną rzecz, potem commit, który poprawia literówkę itp.

Taki przykładowy flow, ale różnie to bywa. Generalnie wolę małe commity. Czasem jak robię kilka rzeczy naraz i zmieniam kilka modułów naraz, to bywa, że to commituję osobno, czasem nawet git add -p (konkretne linijki w pliku). Ale czasem nie i commituję kilka plików naraz. Kieruję się tym, żeby jeden commit to była jakaś mała konkretna rzecz (tylko tą rzeczą może być zarówno "poprawienie literówki" jak i zrobienie dużej funkcjonalności).

Nie ma reguły (chyba, że ty sam albo zespół ci narzuci konkretną metodę pracy z Git. Wtedy najlepiej się dostosować do zespołu, co najwyżej lokalnie robić sobie po swojemu).

1
lukmopy napisał(a):

/ciach/

Jak byście commitowali swoją pracę? 1 commit = 1 wykonany moduł?
Czy jakoś inaczej? :)

Inaczej.
Po pierwsze GitFlow... Ja używam SourceTree, a więc klikam w guziczki i prowadzi mnie za rączkę.
Po drugie - nie 1 commit - 1 moduł, tylko 1 moduł = 1 feature (dokumentacja do GitFlow się kłania).
A w każdym feature pewnie dziesiątki/setki commitów, ale na pewno nie jeden.
A jak już zakończę pracę nad modułem, to robię merge z gałęzią develop.
I tyle.

To jest bardzo proste, ale o tym się dowiesz kiedy zaczniesz tego używać.

1
LowSkiller napisał(a):

Jasne, tu masz kilka na szybko:

  • oporności przy tworzeniu ficzerów, ogarnianiu releasów czy wypuszczaniu hotfixów,
  • nie ma branchowego chaosu - nawet jak jest sporo branchy, to jest je łatwo ogarnąć z GitFlowem i łatwo między nimi przechodzić,
  • nie ma bałaganu w repo i procesach - bo są ogarnięte i uporządkowane (ideałów nie ma, ale jest serio okej),
  • nieogar kilku wersji - z Gitflowem możesz wspierać stare wersje i kodzić nowe (więc ogarnianie kilka wersji apki nie jest bolesne).

No i dla mnie jeden z ważniejszych punktów, to master = produkcja. Boleśnie dowiedziałem się kiedyś, jak bardzo jest to potrzebne. :D

Z mojego doświadczenia git flow stwarza dokładnie te problemy (albo ich nie rozwiązuje, bo takich problemów po prostu nie ma), ale nie będę się kłócił, bo jak u Was działa i pomaga to spoko.

1
lukmopy napisał(a):

Jak byście commitowali swoją pracę? 1 commit = 1 wykonany moduł?

W masterze tak. W feature branczach jeden commit to może być np. pusta struktura klas i metod, napisanych klika testów jednostkowych, przechodzące kilka testów, upgrade zależności. Czasami oznacza to nawet jedną linijkę kodu.
W devie nie ma niczego, bo dev jest zbędny.

LowSkiller napisał(a):
  • oporności przy tworzeniu ficzerów, ogarnianiu releasów czy wypuszczaniu hotfixów,

GitFlow w niczym tu nie pomaga, to jest banalnie osiągalne także przy naturalnym flow.

  • nie ma branchowego chaosu - nawet jak jest sporo branchy, to jest je łatwo ogarnąć z GitFlowem i łatwo między nimi przechodzić,

GitFlow ze swoją porąbaną strukturą wielu długo żyjących gałęzi jest właśnie źródłem chaosu oraz piekła zbędnego mergowania, bo te same zmiany trzeba przepychać wielokrotnie.

No i dla mnie jeden z ważniejszych punktów, to master = produkcja. Boleśnie dowiedziałem się kiedyś, jak bardzo jest to potrzebne. :D

To można mieć bez GitFlowa.

Zawsze zastanawia mnie, czemu ludzie wybierają narzędzie dające pełną wolność twórczą jaką jest Git, żeby potem nałożyć sobie kajdany procesu? Mentalność niewolnicza?

0
somekind napisał(a):

Zawsze zastanawia mnie, czemu ludzie wybierają narzędzie dające pełną wolność twórczą jaką jest Git, żeby potem nałożyć sobie kajdany procesu? Mentalność niewolnicza?

Bo mało kto rozumie co się dzieje w GIT, więc nakłada się kagańce, żeby w miarę ludzie commitowali i wiedzieli co zrobić, żeby na jakąś gałąź coś przenieść, nie robiąc 2 klonów i przenosić WinMergem po linijce ;) Serio, mało kto rozumie git, co najwyżej są wytresowani do kilku komend, coś jak wyuczenie pacierza.

1

@somedev, ale to przecież GitFlow zakłada mergowanie tego samego do dwóch miejsc, np. bugfixa wrzucasz raz do mastera "na produkcje" i drugi raz do "developa". Jak masz tylko feature branch i mastera, to nie masz gdzie merdżować dwa razy, no chyba, że tyle tankujesz, że nie pamiętasz co robiłeś wczoraj. :P

0

No i posiadanie gałęzi integracyjnej developer gdzie hulają testerzy jest opłacalne zanim pójdzie cherry pick do mastera. Jak masz tylko gałąź główną i future branche to co z integracją systemu? Co ze zmianami rozwojowymi, które trwają nieco, więcej niż 1 bugfix? No i nad tymi zmianami pracuje 10 devów. Gdzieś muszą się integrować. Jakby mieli się integrować między swoimi branchami, lub mergować do lokalnego mastera czy inne dziwne rzeczy to każdy robił by to inaczej i była by bieda. Jeden z systemów jaki utrzymuje zawiera 4 żywe gałęzie, do których idą czasem merge, a czasem cherry-pick. Rzadko się spotyka człowieka co dobrze rozumie gita i potrafi się nim posługiwać, bez wpojonej mantry serii commitów, mergów, cherry-picków. Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.

5

@somedev nie wiem czy wiesz, ale git pozwala na robieni rebase / merge na branchu, więc zupełnie nie rozumiem twojego problemu. Nad ficzerem pracujecie na branchu, w międzyczasie regularnie robiąc rebase do mastera, żeby cały czas być w zgodzie z aktualnym masterem. Nie rozumiem też problemu z integracją czy testerami, bo nikt nie broni deployować ficzer brancha i go testować.

Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.

To biznesowa kwestia czy chcesz mieć taki support, ale nawet wtedy nadal nie jest to moim zdaniem żaden problem. Nikt nie broni zrobić brancha z taga i wrzucić tam fixa.
Inna sprawa jeśli macie aktywny, niezależny development dwóch "wersji", ale wtedy to może już lepiej w ogóle to podzielić. Zresztą to i tak marzenie ściętej głowy że możesz ot tak zrobić commita który będzie pasować do obu tych wersji. W praktyce będzie trzeba napisać bugfix do jednej a potem napisać bugfix do drugiej.

0
Shalom napisał(a):

@somedev nie wiem czy wiesz, ale git pozwala na robieni rebase / merge na branchu, więc zupełnie nie rozumiem twojego problemu. Nad ficzerem pracujecie na branchu, w międzyczasie regularnie robiąc rebase do mastera, żeby cały czas być w zgodzie z aktualnym masterem. Nie rozumiem też problemu z integracją czy testerami, bo nikt nie broni deployować ficzer brancha i go testować.

A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.

Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.

To biznesowa kwestia czy chcesz mieć taki support, ale nawet wtedy nadal nie jest to moim zdaniem żaden problem. Nikt nie broni zrobić brancha z taga i wrzucić tam fixa.
Inna sprawa jeśli macie aktywny, niezależny development dwóch "wersji", ale wtedy to może już lepiej w ogóle to podzielić. Zresztą to i tak marzenie ściętej głowy że możesz ot tak zrobić commita który będzie pasować do obu tych wersji. W praktyce będzie trzeba napisać bugfix do jednej a potem napisać bugfix do drugiej.

Nie przesadzałbym. Jeśli zmiany są w dość korowych obszarach to często wystarczy cherry-pick, tylko trzeba testy podwoić.

Ja pokazałem przykłady gdzie są potrzebne gałęzie. Pewnie można to zrobić i z mniejsza ilością, niemniej to jest odpowiedź własnie na pytanie - jest tyle sposobów, że lepiej nałożyć pewne ramy, żeby cały zespół/dział tak samo działali. Nie zawsze musi to być GitFlow, ale każda organizacja powinna wypracować swój flow. Dodatkowo chociażby z powodu wspierania wielu wersji nie jest aktualny argument, że starcza master i future branch.

2

A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.

Przyznam że chyba nie pracowałem nigdy w projekcie, gdzie wiele osób pracowałoby nad zazębiającymi się zmianami w tym samym serwisie w tym samym czasie, tak ze potrzebowałyby widzieć swoje, jeszcze nie dokończone (bo nie na masterze) zmiany. Może przy jakimś większym monolicie taka potrzeba występuje, trudno mi oceniać.

0
  1. Feature branch od develop do nawet bardzo małych tasków. Opcjonalnie zamiast develop może być główny branch nowego dużego modułu
  2. Merge request
  3. Review i poprawki
  4. Rebase squash
  5. Merge do develop/głównego brancha modułu
0

Jakby był jeden słuszny sposób pracy to by każdy go używał ;)

Ja również nie mam developa. Wystarcza mi rebase i bardzo rzadko wczytanie remote brancha.

0
Shalom napisał(a):

A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.

Przyznam że chyba nie pracowałem nigdy w projekcie, gdzie wiele osób pracowałoby nad zazębiającymi się zmianami w tym samym serwisie w tym samym czasie, tak ze potrzebowałyby widzieć swoje, jeszcze nie dokończone (bo nie na masterze) zmiany. Może przy jakimś większym monolicie taka potrzeba występuje, trudno mi oceniać.

Może być tak, że projekt składa się z 10 tasków. Można pracować równoległo -szeregowo. Pierwsze 4 taski zrobiły 2 osoby, po czym chcą wymienić się kodem bo do tasków 5-10 potrzeba zmian z 1-4. Nie mogą tego puścić na master bo to jest nie skończone i nie przetestowane, oraz nie chcemy, żeby komuś podczas release pokazał się np. przycisk lub api bez implementacji, lub funkcja co robi pól rzeczy. Nie mogą tego zostawić na FB bo potrzebują u siebie. Mogą zrobić FB z mastera i domergować 4 pierwsze branche do siebie. Mogę tez mieć 1 integracyjny i z niego/do niego się odbijać. Kolejna zaleta, jak ma się n wersji w utrzymaniu to mając brancha integracyjnego możesz wyciągnąć zmiany z danego projektu/sprintu bez wybierania tego z mastera czy po branchach wchodzących w cały sprint. Nie każdy proces rozwoju oprogramowania wymaga więcej niż master i future branch ale są takie co wymagają. Do tego dochodzą submoduły, a na każdym branchu może być podpięta inna wersja submodułu.... Każdy prawi o takich niepowiązanych mikroserwisach, czystym kodzie etc. Niemniej nie spotkałem się, jeszcze z dużym systemem, który by nie był na tyle skomplikowany, żeby nie wymagał kilku branchów. Pracowałem z monolitami, ale także z rozproszonymi monolitami - wtedy było ciężej, bo ciężej było stwierdzić, czy dane wersje są ze sobą spójne (jak się submoduły pomieszały na commitach). Ofc. podkreślam, że każdy flow trzeba dobrać do odpowiedniego procesu, oraz zewnętrznego ekosystemu, niemniej jest nieprawdą, że cały rozwój wszystkich projektów można sprowadzić do mastera + FB.

4

My preferujemy podejście CI gdzie mamy mastera i feature branche na bieżąco rebase'owane. Dodatkowo feature branche są squashowane co nam daje 1 commit na feature. Jeżeli zmiana jest duża, to dzielona jest na mniejsze. Dzięki temu historia jest liniowa i łatwa do ogarnięcia.

Ja myślę (tak jak @null null), że nie ma jedynie słusznego podejścia. Wszystko zależy od wielkości zespołu i specyfiki projektu. Myślę, że nasze podejście świetnie sprawdza się dla małych zespołów. Dla większych pewnie też. GitFlow natomiast też ma swoje zastosowania. Być może w przypadku kiedy biznes duma 2 lata czy wypuścić dany gotowy już feature. Znam takie przypadki.

Przy okazji napiszę, że irytują mnie wręcz teksty znalezione w internetach typu: "róbcie tak bo to jest fajne!", albo "nie róbcie tak bo to jest be!". Napisz mi jakie widzisz wady i zalety, a ja sam będę decydował co jest dla mnie w danej chwili dobre.

7
somedev napisał(a):

No i posiadanie gałęzi integracyjnej developer gdzie hulają testerzy jest opłacalne zanim pójdzie cherry pick do mastera.

cherry-pick do mastera? To też jakiś wynalazek z GF? Dla mnie brzmi co najmniej niebezpiecznie takie wybieranie losowej zmiany i wrzucanie jej do głównej gałęzi.

Jak masz tylko gałąź główną i future branche to co z integracją systemu?

Nie rozumiem problemu. Robię deploy z gałęzi i testuję.

Co ze zmianami rozwojowymi, które trwają nieco, więcej niż 1 bugfix?

Generalnie, to dopóki ficzer nie jest skończony, to nie jest merdżowany.

No i nad tymi zmianami pracuje 10 devów.

W sensie jeden pisze ify, drugi pętle, trzeci klasy, i tak dalej? Czemu tyle osób nad jednym taskiem? Może lepiej mieć jednego programistę, który zna cały język? ;)

Gdzieś muszą się integrować. Jakby mieli się integrować między swoimi branchami, lub mergować do lokalnego mastera czy inne dziwne rzeczy to każdy robił by to inaczej i była by bieda.

Ale jaka bieda? Jeśli programista A chce się podzielić swoim kodem z innym, to pushuje taką gałąź, programista B ją pobiera i robi swoje rzeczy, jak skończy, to merguje też do niej. Może przedtem nawet zrobić PR dla programisty A. Nie trzeba do tego żadnego certyfikowanego procesu, to się nazywa używanie Gita.

Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.

Dwie wersje niezależnie rozwijane? To właściwie są odrębne aplikacje, więc bezpieczniej mieć dwa repozytoria.
A jeśli stara jest już nierozwijana, to wystarczy zrobić bugfixa z taga. W GF de facto też się to robi, tylko tagi są na masterze.

somedev napisał(a):

A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.

Skoro są takie potrzeby, to prawdopodobnie prościej byłoby podzielić taski sensownie.

somedev napisał(a):

Nie mogą tego zostawić na FB bo potrzebują u siebie.

To może przestać używać GitFlow, i wtedy będą mogli zostawić?

niemniej jest nieprawdą, że cały rozwój wszystkich projektów można sprowadzić do mastera + FB.

Oczywiście, że można, bo gdy używa się Gita, a nie jakiegoś procesu, to nie ma żadnych ograniczeń ani zasad nakładanych na gałęzie. Nikt nie mówi, czy taka gałąż ma trwać 1 dzień czy 3 sprinty, czy ma być na jeden task, na dziesięć tasków czy na pół taska, ile osób może z niej korzystać, czy można ją deployować czy nie. Po prostu używa się gałęzi - tego czegoś, dzięki czemu Git jest taki fajny.
A jak nie ma zakazów ani nakazów, to nie rodzi się patologia procesowa.

Z tego, co widzę, to GitFlow już jest na etapie socjalizmu i bohatersko rozwiązuje problemy, które sam stwarza, a do przydaje się, generalnie gdy:

  • nie ma CD;
  • jest monolit;
  • zespół radośnie tkwi w waterfallu;
  • i nie zna Gita.

Czyli właściwie najlepiej spełnia swoją rolę jako lampka ostrzegawcza przed większymi problemami.

0
somekind napisał(a):
somedev napisał(a):

No i posiadanie gałęzi integracyjnej developer gdzie hulają testerzy jest opłacalne zanim pójdzie cherry pick do mastera.

cherry-pick do mastera? To też jakiś wynalazek z GF? Dla mnie brzmi co najmniej niebezpiecznie takie wybieranie losowej zmiany i wrzucanie jej do głównej gałęzi.

Nie napisałem nigdzie, że rekomenduje czy nawet używam GF. Jak zrobisz squosha a potem commit do mastera to w opisie standardowo wprost widać skąd to pochodzi i zawiera kompletne zmiany. Cherry-pick jak merge jest narzędziem i dobrze potrafić go używać ;)

No i nad tymi zmianami pracuje 10 devów.

W sensie jeden pisze ify, drugi pętle, trzeci klasy, i tak dalej? Czemu tyle osób nad jednym taskiem? Może lepiej mieć jednego programistę, który zna cały język? ;)

Integrujecie się z jakimś API sklepu. Jedna osoba może integrować się z zakresu integracji produktów, drugi zamówień etc. Można robić to w jednym czasie.

Gdzieś muszą się integrować. Jakby mieli się integrować między swoimi branchami, lub mergować do lokalnego mastera czy inne dziwne rzeczy to każdy robił by to inaczej i była by bieda.

Ale jaka bieda? Jeśli programista A chce się podzielić swoim kodem z innym, to pushuje taką gałąź, programista B ją pobiera i robi swoje rzeczy, jak skończy, to merguje też do niej. Może przedtem nawet zrobić PR dla programisty A. Nie trzeba do tego żadnego certyfikowanego procesu, to się nazywa używanie Gita.

A czy ja pisze o ceryfikowanym procesie? Prościej chyba, miec na 1 gałęzi aktualny stan projektu z skończonymi n tematami, niż szukac które tematy już sa ukończone, żeby je sobie pobrac. Łatwiej pobrać 1 gałąź niz n.

Kolejny powód posiadania wielu żywych gałęzi - a bardzo prosta. Wersja A posiada wsparcie. Wersja B wprowadza zmianę zrywając kompatybilność, np. usunięcie pewnej funkcji API. Po drodze pojawia się błąd1, który występuje zarówno na wersji A jak i na B - siłą rzeczy musisz przenosić zmiany do dwóch miejsc.

Dwie wersje niezależnie rozwijane? To właściwie są odrębne aplikacje, więc bezpieczniej mieć dwa repozytoria.
A jeśli stara jest już nierozwijana, to wystarczy zrobić bugfixa z taga. W GF de facto też się to robi, tylko tagi są na masterze.

Różne repo są, czasem wersje ida na forkach, czasem na gałęziach. Tutaj nie upieram się.

somedev napisał(a):

A co mi po rebase, jeśli ja chcę mieć zmiany kolegów ze sprintu, które jeszcze na masterze nie są? Prościej mieć gałąź sprintową, do/od której można zrobić merga, niż dobierać zmiany kolegów.

Skoro są takie potrzeby, to prawdopodobnie prościej byłoby podzielić taski sensownie.

W idealnym świecie ;)

somedev napisał(a):

Nie mogą tego zostawić na FB bo potrzebują u siebie.

To może przestać używać GitFlow, i wtedy będą mogli zostawić?

Nie używam GF, ale prościej jest mieć miejsce gdzie sa aktualne dokończone zmiany co już wspominałem.

niemniej jest nieprawdą, że cały rozwój wszystkich projektów można sprowadzić do mastera + FB.

Oczywiście, że można, bo gdy używa się Gita, a nie jakiegoś procesu, to nie ma żadnych ograniczeń ani zasad nakładanych na gałęzie. Nikt nie mówi, czy taka gałąż ma trwać 1 dzień czy 3 sprinty, czy ma być na jeden task, na dziesięć tasków czy na pół taska, ile osób może z niej korzystać, czy można ją deployować czy nie. Po prostu używa się gałęzi - tego czegoś, dzięki czemu Git jest taki fajny.

Odnoszę wrażenie, że to Ty chcesz przekonać, że nejlepiej miec FB + master i żadnego dodatkowego. Ja używam gita, wiec mam gałęzie pomocnicze.

A jak nie ma zakazów ani nakazów, to nie rodzi się patologia procesowa.

Z tego, co widzę, to GitFlow już jest na etapie socjalizmu i bohatersko rozwiązuje problemy, które sam stwarza, a do przydaje się, generalnie gdy:

  • nie ma CD;
  • jest monolit;
  • zespół radośnie tkwi w waterfallu;
  • i nie zna Gita.

Jest CI/CD - dlatego z brancha integracyjnego stawia się co noc środowisko testowe (bo jest spore), a z mastera leci deploy w procesie CD. Monolit to fakt, ale to nic nadzwyczajnego i rzadko można coś z tym "już" zrobić, a żyć trzeba. Waterfall, agile - znów szufladkujemy, a sądzę, że każda firma ma inny proces tak jak flow na gicie, lub wolna amerykanke. To, że mało osób zna gita od początku pisze.

2

Mi najbardziej podoba się trunk base devwlopment - czyli olewamy wszystko i jedziemy tylko na masterze. Wiele to upraszcza jeżeli ludzie ogarniają

1
somedev napisał(a):

Cherry-pick jak merge jest narzędziem i dobrze potrafić go używać ;)

I to najlepiej z sensem. Bezpieczna droga do mastera wiedzie przez pull request, a cherry pick nie jest dla nich alternatywą. To pomocnicze narzędzie, które służy do skopiowania zmian z jakiegoś commitu do innej gałęzi. Sensowne przypadki użycia, to np. w porzuconej już gałęzi napisałem dobry kawałek kodu albo testu, i chcę go użyć.

Integrujecie się z jakimś API sklepu. Jedna osoba może integrować się z zakresu integracji produktów, drugi zamówień etc. Można robić to w jednym czasie.

To są oddzielne zadania, ergo oddzielne gałęzie. I do mastera mogą też wejść oddzielnie.

Prościej chyba, miec na 1 gałęzi aktualny stan projektu z skończonymi n tematami, niż szukac które tematy już sa ukończone, żeby je sobie pobrac. Łatwiej pobrać 1 gałąź niz n.

I do tego nie trzeba mieć GitFlow, wystarczy master.

Odnoszę wrażenie, że to Ty chcesz przekonać, że nejlepiej miec FB + master i żadnego dodatkowego. Ja używam gita, wiec mam gałęzie pomocnicze.

Też używam Gita, więc mam dziesiątki gałęzi. Dzisiaj stworzyłem z 10 pracując nad jednym taskiem.
Twierdzę jedynie, że nie są potrzebne inne niż master gałęzie żyjące przez cały czas projektu, że master wyłącznie na tagi jest absurdem, że wszystkie zakończone zadania mogą trafiać do mastera, że do releasu nie trzeba gałęzi, bo wystarczy tag, że praca nad ficzerami i bugfixami nie wymaga niczego poza utworzeniem gałęzi na czas tej pracy i zmerdżowania jej później do mastera, i że tego typu gałęzie są wystarczające do wymiany kodu między członkami zespołu - bo po to właśnie są gałęzie. A skrótu FB używam niezależnie, czy w gałęzi chodzi o task, story, ficzer, buga czy epic.
Więcej długo trwających gałęzi obciągniętych skomplikowanym procesem to tylko więcej nikomu niepotrzebnej roboty ze scalaniem zmian.

0

Odnoszę wrażenie, że zmieniasz zeznania. Nie pisałeś o gałęziach na stałe (zresztą FB nie są na stałe) tylko ogólnie o gałęziach. Niemniej jeśli nie zakładasz branchu, który trwa przez sprint to jak u Ciebie CI buduje środowiska testowe? Ręcznie konfiguruje się procesy, czy macie jakąś logikę zbierania kodu z gałęzi "zakończonych"?

0
somedev napisał(a):

Odnoszę wrażenie, że zmieniasz zeznania. Nie pisałeś o gałęziach na stałe (zresztą FB nie są na stałe) tylko ogólnie o gałęziach. Niemniej jeśli nie zakładasz branchu, który trwa przez sprint to jak u Ciebie CI buduje środowiska testowe? Ręcznie konfiguruje się procesy, czy macie jakąś logikę zbierania kodu z gałęzi "zakończonych"?

To nie wystarczy w TeamCity wybrać swojego brancha przy tasku do stawiania środowiska testowego i kliknac build? Co dodatkowo konfigurowac?

0

No jeśli future boiło na raz pare osób i żeby przetestować całość to musisz mieć albo zmiany na jednej gałezi, albo pozbierać z kilku. Nie chce klikać sam, tylko chcę, żeby co noc zbudowało się środowisko z brnacha integracyjnego (który tez zmiania się co jakiś czas, ale to konfiguruje się raz na parę tygodni). Nie puszczę tego w trakcie dnia bo zepsuje obecne środowisko, a buduje sie kilka godzin.

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