[szmichal]

#programowanie

Co oprócz git-flow do zarządzania repozytorium? Moim zdaniem ten nie zawsze się sprawdza, np wtedy kiedy polegamy na plikach wygenerowany przy buildzie. Mamy jednocześnie zmiany na dwóch branchach co powoduje paskudne konflikty

[GotoFinal]

@szmichal: co to za pliki bo brzmi wtedy jak coś co nie musi (lub nawet nie powinno) być pod gitem jak się zmienia tak bardzo przy innych nie związanych ze sobą zmianach.

[szmichal]

@GotoFinal: snapshot EFa, .NET. oczywiście nie przy każdym buildzie tworzy się nowy ale na jego podstawie tworzą się migracje

[szmichal]

@GotoFinal: imho w ogóle nie powinno się używać EFowych automatycznych migracji tylko pisać je ręcznie, nie byłoby problemu

[Hauleth]

@szmichal: nie cierpię GitFlow i uważam go za szkodliwe podejście. A co do plików generowanych to możesz dodać .gitattributes by usprawnić merge tych plików

[Saly]

@szmichal: szczerze mówiąc to wszystko, git flow to rak. Najbardziej lubię trunk driven development, bo jest prosty i historia repo prowadzonego w takiej konwencji jest bardzo przyjemna do analizy

[szmichal]

@Saly: Dobrze poprowadzony git flow jest w pyte, ale nie kiedy są szybkie wrzutki na proda czy innego stage'a xD To raczej nie jest podejście dla niedojrzałego zespołu a tym bardziej biznesu

[kiciek]

@szmichal: W moich projektach lepiej się sprawdza coś bliskiego do GitFlow, niż to co ten pan proponuje, ale w niektórych kwestiach warto go posłuchać. Tu wymienia kilka źródeł.
https://www.youtube.com/watch?v=_w6TwnLCFwA&t=795s

[Hauleth]

@szmichal: GitFlow strasznie duplikuje wszystkie rzeczy. IMHO Trunk-based jest zdecydowanie bardziej naturalny

[WhiskyRomeo]

@szmichal: github flow. Połączonym z dedykowanym środowiskiem testowym per developer na chmurze. Prosto, przyjemnie i drogo, coby nie bylo za idealnie.

[GotoFinal]

@Hauleth: @WhiskyRomeo: @szmichal: imho pełny gitflow to jest spoko ale jak utrzymujesz realne oprogramowanie, takie które ludzie używają w różnych wersjach. Bo jak ktoś potrzebuje tak skomplikowanego flow do developowania wewnętrzego serwisu który jest w 100% kontrolowany przez was... to raczej smutne.
Co też oznacza że trochę przestzarzałe podejście, bo coraz rzadziej wypuszcza się duże releasy, tylko małe aktualizacje, często kilka razy w miesiącu albo i nawet z dnia

[asunez]

@szmichal: Przecież nawet docsy majkrosoftu mówią jak rozwiązywać problem migracji i snapshotu tak żeby się z tym nie #!$%@?

[szmichal]

@asunez: show me

[asunez]

@szmichal: Tak na dobra sprawę to żadna wiedza tajemna xd

https://docs.microsoft.com/en-us/ef/core/managing-schemas/migrations/teams

[szmichal]

@asunez: ja jak jest konflikt generowalem nowego snapshota i tyle. Tylko wcześniej zapadły pewne decyzje i czasami muszę walczyć z konfliktami ehh