Praca w GIT tylko na Masterze

Jako, że rozwinęła się dyskusja z @Shalom w komentarzach to tworzę nowy wątek bo może inni też nie znają takiego podejścia.

Jak pracowałem w Instagramie to pracowaliśmy wszyscy na jednym branchu - Master. Nie było feature branchy (z tego co wiem to nadal nie ma bo to się sprawdza)

Zalety:

• Łatwiejsza współpraca. Nie trzeba się zastanawiać w jakim repo czy branchu dany feature jest rozwijany.
• Łatwiej dzielić zmiany na mniejsze części.
• Łatwiej cofać zmiany jeśli jest to konieczne
• Można kontrolować wydajność danych feature jednocześnie w trakcie rozwoju bez dodatkowych narzutów

Skoro każdy feature jest rozwijany na masterze to jak dostarczamy kod do użytkowników?
W Instagramie to wyglądało/wygląda tak, że każdy feature jest dostępny najpierw tylko dla określonych użytkowników np. dla programistów. Potem dla QA (coś w tym stylu, co prawda w Instagramie inaczej te role się nazywały i miały trochę też inne obowiązki) - tutaj mogą dać już feedback (wcześniej też) żeby programiści mogli kontynuować pracę.

Następnie dla wszystkich pracowników. Potem część użytkowników np. 0,5% USA. Jeśli wszystko jest ok to feature jest włączany dla wszystkich.
Tak proces może trwać tydzień a może trwać i miesiąc.

Pomiędzy są też load testy żeby wiedzieć czy jeśli każdy by mógł używać to serwery by to wytrzymały itd.

Jak myślicie jak często wrzucany jest kod na Produkcję? Raz na tydzień? Raz na dzień? A co powiecie na raz na commit?
W tamtym okresie było to około 30-70 rolloutów na dzień.
Taki typowy commit znajduje się na prodzie w ciągu godziny od wejścia do mastera.

Wymagania:

• Każda zmiana musi być działająca
• Code review
• unit testy
• Zbieranie informacji o błędach i porównywanie liczby błędów pomiędzy serwerami. Czyli zanim zmiana pójdzie na np. 40 000 serwerów to najpierw ląduje na 2-3 serwery i porównywany jest % błędów. Jeśli znacznie rośnie to wiadome, że coś jest nie tak.
• Alarmy itd. żeby jak najszybciej wykrywać błędy

Łatwiejsza współpraca

W jaki sposób? Zrobiłem jakieś zmiany i chciałbym żeby kolega z biurka obok zrobił resztę pod ten feature. W jaki sposób się to dzieje? Jak przekazuje mu te zmiany? Pushnąć do mastera jeszcze nie mogę, bo to dopiero połowa kodu i w ogóle nie działa.

Każda zmiana musi być działająca
Code review

W jaki sposób to się dzieje skoro nie ma brancha? Jasne, mogę lokalnie puścić sobie unit testy, ale z jakimiś e2e już ciężko. Podobnie z code review, w jaki sposób ktoś inny ma dostęp do mojego kodu zanim wrzucę go do origin/master? Deploujesz z palca swoją lokalną wersje na jakimś serwerze na którym leci e2e?

Bo na dobrą sprawę to brzmi jak developowowanie w branchu, tylko ze lokalnym i push na koniec do mastera jak już jest zrobione, czyli nic innego jak merge tego twojego lokalnego brancha do origin/master. Tylko ze, no właśnie, wszystko to jest tylko lokalnie u ciebie na komputerze.

Nie znam się to się wypowiem. Wydaje mi się, że w przypadku Instagrama mieliście do czynienia z mocno spójnym produktem, gdzie głównie chodziło o jego doskonalenie a nie rozwój wszerz. Mogę się mylić, nawet nie mam IG, ale wygląda jak prosty serwis z obrazkami + txt. o skomplikowaniu rzędu jbzd.pl dlatego mogło się to udać. W przypadku bardzo rozległych funkcjonalnie projektów o takiej "modułowej" strukturze, gdzie poszczególne ficzery i aspekty mogą być ze sobą luźno związane, albo wręcz prawie niezależne. I np. zespoły A, B, C nie mają żadnego, albo niewielki pożytek z tego, że pracują z kodem uwzględniającym najnowsze zmiany dokonane przez zespół D, a jednocześnie jakaś wtopa na poszczególnym ficzerze powoduje wycofanie tylko jego gałęzi, reszta działa. Łatiej też koordynować pewnie prace w obrębie gałęzi i dopiero je między sobą, niż gdyby to była całość - to wymaga większego stopnia organizacji i musi byc wrażliwsze na usterki (jak każdy zcentralizowany system). Skądś się gałęzie wzięły i przyjęły i na pewno wyewolułowały z liniowego modelu, bo tak jest efektywniej, bo każda komplikacja o ile nie daje bonusów jest wypierana i upraszczana w przyrodzie.

@Shalom:

Shalom napisał(a):

Łatwiejsza współpraca

W jaki sposób? Zrobiłem jakieś zmiany i chciałbym żeby kolega z biurka obok zrobił resztę pod ten feature. W jaki sposób się to dzieje? Jak przekazuje mu te zmiany? Pushnąć do mastera jeszcze nie mogę, bo to dopiero połowa kodu i w ogóle nie działa.

Nie musisz zastanawiać się w jakim repo czy jakim branchu poszczególny feature jest rozwijany. Piszesz kod, który wprowadza coś małego co nie rozwala innych rzeczy i nie aktywujesz go dla nikogo/aktywujesz go tylko dla programistów.

Każda zmiana musi być działająca
Code review

W jaki sposób to się dzieje skoro nie ma brancha? Jasne, mogę lokalnie puścić sobie unit testy, ale z jakimiś e2e już ciężko. Podobnie z code review, w jaki sposób ktoś inny ma dostęp do mojego kodu zanim wrzucę go do origin/master? Deploujesz z palca swoją lokalną wersje na jakimś serwerze na którym leci e2e?

Lokalne testy, lintery i inne tego typu wystarczają, żeby pchnąć to dalej. Praktycznie wszystko możesz odpalić lokalnie.

Co do code review. Nie chodzi o to, że masz zakaz stworzenia brancha. Idea polega na tym, że nie masz długich gałęzi, które na wiele dni/tygodni są tworzone równolegle.

Pozwala to uniknąć:

• dużych mergy
• nagłego dostarczenie całej funkonalności do mastera, która nie była testowana na serwerach produkyjnch
• rozjazdu modułu, który byl np. modyfikowany na różne sposoby w dwóch dużych feature branach. Ale to można podpiać pod problem z mergami bardziej ogólnie

Bo na dobrą sprawę to brzmi jak developowowanie w branchu, tylko ze lokalnym i push na koniec do mastera jak już jest zrobione, czyli nic innego jak merge tego twojego lokalnego brancha do origin/master. Tylko ze, no właśnie, wszystko to jest tylko lokalnie u ciebie na komputerze.

Nie do końca. Po wypychasz jak najmniejsze zmiany jakie jesteś w stanie wypchać żeby nic nie zepsuły. A w takim standardowym podejściu wypychasz całą gotową funkcjonalność.

PanamaJoe napisał(a):

Nie znam się to się wypowiem. Wydaje mi się, że w przypadku Instagrama mieliście do czynienia z mocno spójnym produktem, gdzie głównie chodziło o >
jego doskonalenie a nie rozwój wszerz.

Funkconalności np. Direct Message, Instastory, Filmy, Proponowanie obserwowanych osób operate na ML, Reklamy (ML, personalizacja itd.), Filtry graficzne.
Milard użytkowników do obłużenia, tutaj każda rzecz musi być przemyślana pod skalę.

Mogę się mylić, nawet nie mam IG, ale wygląda jak prosty serwis z obrazkami + txt. o skomplikowaniu rzędu jbzd.pl dlatego mogło się to udać. W przypadku bardzo rozległych funkcjonalnie projektów o takiej "modułowej" strukturze, gdzie poszczególne ficzery i aspekty mogą być ze sobą luźno związane, albo wręcz prawie niezależne. I np. zespoły A, B, C nie mają żadnego, albo niewielki pożytek z tego, że pracują z kodem uwzględniającym najnowsze zmiany dokonane przez zespół D, a jednocześnie jakaś wtopa na poszczególnym ficzerze powoduje wycofanie tylko jego gałęzi, reszta działa.

Problem bardzo często potem pojawia się przy mergach, przy testowaniu na serwerach produkcyjnych, przy load testach.

Musisz zrozumieć jaka to jest skala. Na tamten momend to było 10000 - 30000 serwerów. Dana funkcojnalność może wymagać dodania np. 1000 serwerów bo jest niewydajna. I po to wypuszcza się to jak najszbyciej (od razu) na serwery produkcyjne ale nie udostępnia użytkownikom. Dzięki temu możemy stworzyć takie metryki jak np.:

• Ta funkcjonalność wymaga dodania 400 serwerów. Zastanów się czy nie da się jej zoptymalizować.
• Ta funkojnalnosć spowodowała o 200 błędów więcej na tym serwerze czy serwer bez tej funckjonalności.

Takie podejście oczywiście wymaga kompromisów ale przy takiej skali się to sprawdzało. Deploy na 20000 serwerów trwał około 10 minut~

anonimowy napisał(a):

PanamaJoe napisał(a):

Nie znam się to się wypowiem. Wydaje mi się, że w przypadku Instagrama mieliście do czynienia z mocno spójnym produktem, gdzie głównie chodziło o >
jego doskonalenie a nie rozwój wszerz.

Funkconalności np. Direct Message, Instastory, Filmy, Proponowanie obserwowanych osób operate na ML, Reklamy (ML, personalizacja itd.), Filtry graficzne.
Milard użytkowników do obłużenia, tutaj każda rzecz musi być przemyślana pod skalę.

No ale porównaj sobie to do jakiegoś np. CRMa do zarządzania fabryką - ile tam będziesz miał różnych wątków i funkcji. Różnica o rzędy wielkości. Tak skala - masz rację, dlatego pisałem o rozległości systemu wszerz, skalę rozumiem wzdłuż :D Namieszałem? :D

Problem bardzo często potem pojawia się przy mergach, przy testowaniu na serwerach produkcyjnych, przy load testach.

Musisz zrozumieć jaka to jest skala. Na tamten momend to było 10000 - 30000 serwerów. Dana funkcojnalność może wymagać dodania np. 1000 serwerów bo jest niewydajna. I po to wypuszcza się to jak najszbyciej (od razu) na serwery produkcyjne ale nie udostępnia użytkownikom. Dzięki temu możemy stworzyć takie metryki jak np.:

• Ta funkcjonalność wymaga dodania 400 serwerów. Zastanów się czy nie da się jej zoptymalizować.
• Ta funkojnalnosć spowodowała o 200 błędów więcej na tym serwerze czy serwer bez tej funckjonalności.

Takie podejście oczywiście wymaga kompromisów ale przy takiej skali się to sprawdzało. Deploy na 20000 serwerów trwał około 10 minut~

Ja jestem wielkim fanem Waszej pracy tylko na masterze. I wierzę, że to się u Was sprawdzało i że to co opisujesz powyżej było powodem dlaczego tak działaliście. Widocznie było to też powodem, ze opłacało się zrezygnować z gałęzi. Nie sugerowałem, że gałęzie to dogmat, tylko, że w innych przypadkach prawdopodobnie będą się lepiej sprawdzać, niż jeden master. Jeszcze raz: nie krytykuję.

Nie potrafił bym tak pracować i nie rozumiem jak można tak pracować. Robię kilka commitów na godzinę prawie zawsze z kodem który się po prostu sypie, ale wolę to puścić by nie zginęło. Poza tym robienie na jednym branchu przez kilka osób to zawsze problemy z konfliktami.

Nie wyobrażam sobie czegoś takiego. Robię coś co zajmuje np. kilka dni i mam:
1)albo nie wrzucać czegoś bo się master zyebie a lokalnie moge stracić dane bo coś tam -> bez sensu
2)wrzucać uber małe commity które i tak moga coś zepsuć -> bez sensu

mr_jaro napisał(a):

Poza tym robienie na jednym branchu przez kilka osób to zawsze problemy z konfliktami.

Może to jest właśnie sztuka delegowania zadań tak, żeby nie było konfliktów. Nie wiemy jak to organizacyjnie wygląda od środka.

@bakunet: nie da się, zawsze są obszary które są wspólne pomiędzy modułami, np routing.

Brzmi jak trunk. Można i tak nie jest to jakiś ekstremalny model, ale bez canary release i rozbudowanego monitoringu to ciężko prowadzić taki development w większej grupie. Bardziej mnie ciekawi jak często się konfliktowaliście kiedy jednocześnie wszyscy siedzą na jednym branchu i jak upierdliwe było rozwiązywanie konfliktów ;)

mr_jaro napisał(a):

@bakunet: nie da się, zawsze są obszary które są wspólne pomiędzy modułami, np routing.

Ale taki routing się nie zmienia z dnia na dzień i może przy odpowiedniej kulturze i dyscyplinie takie rzeczy są konsultowane i uważnie sprawdzane. Ale możesz mieć rację, nie musi być to łatwe i ciekaw jestem jak to jest zorganizowane :)

Obstawiam, że op używał gitlab flow tylko nie zna nomenklatury bo sam tego flow nie zaimplementował. Zamiast tego używa argumentów typu: "u nas w UK".

Prosta rzecz, żeby zrobić code review potrzebujesz feature brancha.

anonimowy napisał(a):

Nie chodzi o to, że masz zakaz stworzenia brancha. Idea polega na tym, że nie masz długich gałęzi, które na wiele dni/tygodni są tworzone równolegle.

No to halo, bo praca na jednej gałęzi, a unikanie branchy typu development, to co innego. Dosłowna praca na jednej gałęzi to doskonały sposób, by poświęcać połowę swojego czasu dziennie na rozwiązywanie konfliktów oraz zawalenie sobie historii Merge branch 'origin/master' into 'master'. Zaś tworzenie feature'ów w osobnych gałęziach, ale częste ich merge'owanie, oraz trzymanie tylko jednej głównej gałęzi, zamiast jakiegoś podziału master/staging/development, to - jak dla mnie - słuszne podejście (choć nie wszędzie pasujące).

cmd napisał(a):

Brzmi jak trunk. Można i tak nie jest to jakiś ekstremalny model, ale bez canary release i rozbudowanego monitoringu to ciężko prowadzić taki development w większej grupie. Bardziej mnie ciekawi jak często się konfliktowaliście kiedy jednocześnie wszyscy siedzą na jednym branchu i jak upierdliwe było rozwiązywanie konfliktów ;)

Dlatego nie napisałem, że jest to idealne rozwiązanie dla wszystkich i napisałem właśnie o wymaganym canary release (opisałem jak to u nas wygląda bo nie każdy wie co to). Monitoring jest niesamowicie rozbudowany na co mogą sobie tylko pozwolić bogate firmy.

Kilku z was wspomniało konflikty. To czy nie uważacie, że lepiej na bieżąco rozwiązywać 2-3 konflikty jakieś małe niż przy mergu ogromnego feature brancha? Tak samo przy normalnym flow też przecież robicie merge na bieżąco żeby później nie rozwiązywać konfliktu na każdym pliku. Różnica jest taka, że jak zmergujecie swój ogromny feature branch do sprint/dev/master to każdy inny dev z innego brancha będzie musiał rozwiązać wszystkie wasze konflikty za jednym razem.

twoj_stary_pijany napisał(a):

Obstawiam, że op używał gitlab flow tylko nie zna nomenklatury bo sam tego flow nie zaimplementował. Zamiast tego używa argumentów typu: "u nas w UK".

Prosta rzecz, żeby zrobić code review potrzebujesz feature brancha.
Tak jak pisałem - nie ma feature branchy.

Sensacyjny Sebastian napisał(a):

anonimowy napisał(a):

Nie chodzi o to, że masz zakaz stworzenia brancha. Idea polega na tym, że nie masz długich gałęzi, które na wiele dni/tygodni są tworzone równolegle.

No to halo, bo praca na jednej gałęzi, a unikanie branchy typu development, to co innego. Dosłowna praca na jednej gałęzi to doskonały sposób, by poświęcać połowę swojego czasu dziennie na rozwiązywanie konfliktów oraz zawalenie sobie historii Merge branch 'origin/master' into 'master'. Zaś tworzenie feature'ów w osobnych gałęziach, ale częste ich merge'owanie, oraz trzymanie tylko jednej głównej gałęzi, zamiast jakiegoś podziału master/staging/development, to - jak dla mnie - słuszne podejście (choć nie wszędzie pasujące).

Tak jak pisałem konflikty trzeba rozwiązywać zawsze. Tutaj różnica jest taka, że je rozwiązujesz od razu i masz do rozwiązania np. 2-3 commity a nie jakiś ogromny feature branch.
Jest coś takiego jak rebase i historia jest czysta jak łza.

Nie wyobrażam sobie oczywiście takiego podejścia w firmie, która ma mniej niż 50 devów na projekt bo sprawienie żeby to działało wymagało sporych pokładów pracy.

hehehe no właśnie nie, im więcej devów tym bardziej potrzebne są branche, na masterze można sobie siedzieć jak pracujesz sam, przy 2 osobach już się zaczynają problemy.

Ja tu dostrzegam pewne nieporozumienie, a mianowicie definicję tego co oznacza praca "tylko na masterze" lub- patrząc na to z drugiej strony- czym jest "feature" branch. Już kilka osób to wypomniało tutaj.

Feature branch nie musi oznaczać długo żyjącego brancha. I w zasadzie tyle w temacie. To że ktoś nie nazwie tego feature branchem nie ma znaczenia, to kwestia względna.

Tutaj cytat z autora wątku:

Co do code review. Nie chodzi o to, że masz zakaz stworzenia brancha. Idea polega na tym, że nie masz długich gałęzi, które na wiele dni/tygodni są tworzone równolegle.

No właśnie, czyli praca nie odbywa się tylko na masterze, bo jeśli masz krótkotrwały branch na którym kodujesz, a następnie tworzysz z tego brancha PR i mergujesz do mastera (skąd jest deployment na prod) to siłą rzeczy pracujesz na więcej niż jednym branchu.

To nic odkrywczego, to się nazywa trunk-based development jak już było wspomniane. I to w zasadzie tyle, tytuł wątku jest mylny i temat można zakończyć. Dziękuję, dobranoc.

Pracowałem w ten sposób na monorepo, działa i faktycznie się sprawdza.

Master always in deployable state.
Funkcjonalności rozgrzebane są budowane "cegła po cegle" na masterze, nie ma kłopotów żeby kilka osób pracowało nad jedną rzeczą.
Prawie zero straty czasu na merge, bo merguje się na bieżąco często po kilka PR dziennie.

Ja osobiście korzystałem z krótko żyjących feature branchy, ale mogę sobie wyobrazić że jakby przejść do ekstremum: branch potrzebny tylko na jeden niewielki komit, to stają się one zbędne. Po prostu master -> nowy kommit -> push master z komitem -> review -> merge -> produkcja.

Ok. Ale to w takim razie jak zrozumiałem każda funkcjonalność jest oifowana. Najpierw ifujesz swój commit, że nie ma review, potem test, pilotaż itd. No to na każdą linijkę nowego kodu masz dodatkowy if i jakieś 100 ifów/funkcjonalność. No i muszą być osoby centralnie sterujące tą ifologią. Dodatków co w sytuacji kiedy jednak ktoś rezygnuje z danej funkcjolnosci, to wszystko zostaje w masterze z if(false) czy szukacie wtedy comit po commicie co trzeba usunąć? Bo przecież równolegle weszły commity które są potrzebne.

Nie jest tak źle. Deploy == restart usługi. Sporo flag operuje na ustawieniach beanów w kontenerze więc masz w kontenerze:

MyDuperSuperNewCache cacheV2() {
  return FeatureFlags.cacheV2.enabled ? new MySuperDupperNewCache() : new NoOpCache();
}

W praktyce 90% kodu feature flag w kontenerze i 10% w kodzie. Oczywiście te flagi się potem usuwa jak się już coś wygrzeje na produkcji.

EDIT: Flagi które są zaifowane w kodzie to często hot reload czyli można zmienić wartość na żywym organizmie. Daje to pole do popisu, bo można np. włączyć testowo na 1 maszynie na próbę i jak nic się nie sypie to włączyć na pozostałych.

Usuwanie kodu jest zawsze trudne. W tym podejściu if'owlogia i feature flagi pomagają a nie przeszkadzają, bo usuwa się zazwyczaj 3 czy 4 lata po napisaniu...

Ok czy to podejście o którym piszesz @anonimowy to jest po prostu trunk based development? Bo dla mnie to mniej więcej tak wygląda i też mi się ta koncepcja podoba.

Sam właśnie u siebie zaproponowałem odejście od tradycyjnego gitflow właśnie w stronę TBD bo obecnie mamy monorepo dla kilku projektów (ten sam core, ale różne fronty i zestawy funkcjonalności). Robienie większych releasów to był zawsze problem. Niestety w naszym przypadku rezygnacja z testów manualnych była niemożliwa, więc trochę musieliśmy pokombinować z testowaniem pojedynczych featrów (mamy teraz system tak skonfigurowany, że tester może sobie postawić środowisko testowe dla dowolnego feature brancha).

Lepiej deployować często drobne zmiany niż co 2 tygodnie większe merge. Łatwiej też w takim podejściu szybko usuwać ewentualną awarię - gdy na przykład wrzucasz 10 featerów na raz i coś się sypie to jest znacznie więcej możliwych błędów. U nas też to z grubsza ma działać tak, że najpierw deploye na mniej obciążone środowiska a jak się wyleży dzień-dwa to uruchomienie na pozostałych środowiskach.

To co zauważyłem to zmiana na takie podejście trochę wymusza też odejście od typowego Scruma i przejście na metodyki ciągłe typu kanban. U nas w sumie to właśnie przejście na Kanbana spowodowało myślenie o TBD.

Drugie przemyślenie to jest fajne dla firm produktowych lub ewentualnie do projektów, gdzie jest duże zaangażowanie ze strony SH (dedykowany zespół z długoterminowym projektem). W przypadku typowych projektów w SH, gdzie developerzy pracują w kilku projektach na raz, każdy ciśnie na terminy, nie ma sensownego SLA itp. to już chyba lepiej sprawdza się Scrum ze sprintami i realeasami.

Podejrzewam, ze to co miał na myśli OP pisząc "nie ma branczy" to raczej "nie ma długożyjących, współdzielonych branczy", czyli coś na zasadzie:
jest "master", czy tam "trunk", to tylko nazwa. Robię zmianę na "swoim" branczu, zmiana jest testowana, skanowana, ostatecznie przechodzi przez review i jest natychmiast merdżowana do głównego strumienia. Jeżeli jest to jakiś ficzer, który dopiero zaczyna być tworzony, to zwyczajnie jest schowany za jakimś feature switch, więc testerzy mogą sobie testować, koledzy również, a zmiana może iść bezpośrednio na produkcję i wciąż być niewidoczna dla użytkownika końcowego. Jak wszystko jest już zrobione, działające marketing przestawia pstryczek i użytkownicy (u których odpowiednia wersja jest na telefonach od tygodnia) dostają do niej dostęp.

A potem się dziwić, że programiści padają na umiejętnościach miękkich skoro op nie potrafi nawet się wysłowić jak tak naprawdę pracuje.

mr_jaro napisał(a):

A potem się dziwić, że programiści padają na umiejętnościach miękkich skoro op nie potrafi nawet się wysłowić jak tak naprawdę pracuje.

Czemu zakładacie, że on nie wie co robi. Może jest dokładnie tak jak pisze, że wszyscy na masterze + megarozbudowany system koordynacji tego co robią i jakaś paranoiczna separacja zadań, żeby nie zachodziły na siebie ich zakresy i nie wpływały na siebie (brzmi jak utopia).

PanamaJoe napisał(a):

Czemu zakładacie, że on nie wie co robi.

Brzytwa Ockhama
Jest bardziej prawdopodobne, że użył bezsensownego skrótu myślowego albo nie wie czym jest gałąź w Gicie niż to, że codziennie upuszcza sobie kowadło na stopy.

Może jest dokładnie tak jak pisze, że wszyscy na masterze + megarozbudowany system koordynacji tego co robią i jakaś paranoiczna separacja zadań, żeby nie zachodziły na siebie ich zakresy i nie wpływały na siebie (brzmi jak utopia).

Niewykonalne nawet dla dwóch programistów siedzących nad jednym API z trzema endpointami, co dopiero dla jakiegoś ogromnego systemu u lidera branży.

Zastanawia mnie dlaczego uważacie, że konflikty pomiędzy różnymi gałęziami kodu biorą się z nieistnienia różnych gałęzi kodu?
Scenariusz z git-flow:
jest master (pardonnez mon francais "main") , rusza sprint tworzone są 2 ficzergałęzie zaczyna się 2 tygodnie pisania kodu. Sprint się kończy i powodzenia dla drugiego w rozwiązywaniu konfliktów, które nie istnieją w git-flow. Przecież tu nie ma żadnej magii - konflikty biorą się z tego, że 2 różne osoby w tym samym czasie zmieniły jakiś kawałek kodu, jedyne co robi git-flow to odkłada w czasie konieczność ich mergowania, ale jest to trudniejsze, bo konfliktów jest więcej i trudniej dojść o co biega w cudzych zmianach.

OP utrzymuje że pracuje w Instagramie. Tak więc nie zakładał bym że jest juniorem który nie ma pojęcia co robi. Może jest praktykantem który wygrał praktyki w dolinie? A może przeszedł rygorystyczny proces rekrutacji i faktycznie opisuje to co widzi. (Może też kłamać, wiadomo Internet).

FANGI mają różne dziwne infrastrukturalne projekty, Google to chyba tutaj nalepszy przykład mieli k8s zanim wymyślili k8s, nawet teraz ich narzędzia i podejście do pracy jest o rząd wielkości lepsze niż to co widać w innych firmach informatycznych.

Być może architekci z Insta doszli do wniosku że ludzie nie rozumieją branchy i napisali jakąś nakładkę na gita - branchless git, który zdejmuje z programistów potrzebę myślenia o branchach itp. Wszystko zostało za nich zautomatyzowane. To że na Polskim podwórku firm nie stać na tego typu ambitne projekty nie znaczy że inni ich nie robią...

EDIT: Ja PRDL, o proszę jakby mi ktoś nazwę podkradł https://github.com/arxanas/git-branchless 1.4k gwiazdeczek... - także panowie i panie czas posypać głowę popiołem...

piotrpo napisał(a):

Zastanawia mnie dlaczego uważacie, że konflikty pomiędzy różnymi gałęziami kodu biorą się z nieistnienia różnych gałęzi kodu?

Bo Git to nie SVN, i nie da się mieć jednej gałęzi. masterów jest tyle, ilu jest deweloperów + origin.

Scenariusz z git-flow:

Git flow to właśnie jeden z raków, który prowadzi do większej liczby konfliktów, bo wymaga ciągłego merdżowania między długo żyjącymi gałęziami, więc w sumie nie wiem jak można tego używać jako jakiegoś argumentu.

@0xmarcin: ale weź przeczytaj jakieś dowolne opracowanie różnych koncepcji, pierwszy artykuł z brzegu - https://flagsmith.com/blog/git-branching-and-feature-flags/ Zawsze masz jakieś branche. Ja rozumiem, że możesz mieć nawet odblokowane pushowanie bezpośrednio do mastera i jakieś hooki, które uruchamiają unity przed tym. Ale w jaki sposób robisz code review nie robiąc diffa między branchami lub branchami forka?

Co z tego, że gość pracuje w instagramie? Może tam tylko sprząta? Albo na rozmowie miał rozwiązywanie zagadek, sortowanie bąbelkowe i grafy. Na rozmowach do fanga nie pytają o gita.

Jeżeli ten brancheless https://github.com/arxanas/git-branchless
odzwierciedla to co jest w Googlu, to code review jest robione na poziomie commita, który trafia bezpośrednio do mastera - pisałem o tym podejściu w innym wątku. Oczywiście pod spodem tworzy się kopia robocza plików, które się modyfikuje - bez tego nie dałoby się pracować :) Zakładam, że w Insta może być podobnie.

Na pewno radziłbym zachować otwartą głowę, bo większość wypowiadających się tutaj prezentuje tzw. fixed mindset - ja wiem najlepiej, a OP to tam pewnie zmywał w tym Instagramie i w ogóle nie wie jak działa git. Wstydźcie się :)

To mi brzmi jak Gerrit (bodajże Google tego używa, a przynajmniej to stworzyli) ze specyficznym single-commit workflow.
Gdzie devs pushuje pojedynczy commit (do mastera) do review, a ewntualne poprawki są amendowane do tego commita. Takie podejście niby wymusza mniejsze zmiany i lepszą synchronizacje z masterem. (https://gerrit-review.googlesource.com/Documentation/intro-gerrit-walkthrough.html)
Chociaż nie wiem jak wygląda współpraca N>1 devsów nad tym samym featurem w tym przypadku