Git Branch Strategy
Zdefiniowanie standardu branch'owania projektów w gicie.
zebranie informacji od zespołów w jaki sposób branchują repozytoria
przeanalizowanie popularnych strategii: Git Flow, GitHub Flow, GitLab Flow
wybranie optymalnej strategii, stworzenie standardu i wdrożenie w zespołach
wypracowany za czasów OKR standard: Standard Procesu CI/CD (może warto coś z tego wyciągnąć)
(blue star) Perspektywa zespołów
Stosowany Git Flow (https://www.atlassian.com/pl/git/tutorials/comparing-workflows/gitflow-workflow) w konfiguracji z mavenem.
W nowych projektach (code-quality-new) stosowany plugin com.amashchenko.maven.plugin:gitflow-maven-plugin
W starszych projektach (code-quality-legacy) stosowany plugin external.atlassian.jgitflow:jgitflow-maven-plugin
W najstarszych projektach (code-quality-debt) branche: master, develop, feature. Ręczny merge develop → master.
W zasadzie nie robimy hotfix-ów - nie pamiętam żeby nam się przydarzyło.
(lightbulb) Pomysły i propozycje
tworzenie szablonów/templates, dzięki czemu w gitlab-ci jest głównie sama logika, a nie makaronowy ciąg wykonywanych procesów
blokowanie mastera, tak aby nie było możliwoście robienia z niego git push’a. Powoduje to konieczność tworzenia odrębnych branch’y do pracy i wystawiania mr'ów do mastera (lepsza historia pracy, łatwiej pamiętać o review)