[mariecziek]

Czołem mirki.
Możecie podzielić się doświadczeniem w jaki sposób przebiega wasza praca z gitem? Chodzi mi o workflow od powstania nowego brancha do zmergowania go do mastera.

Teraz w pracy mam tak, że beta = master, więc tworzę nowy branch z branchu beta, wykonuję na nim jakieś zmiany, następnie robię merge do branchu alpha (jeżeli powstają konflikty, to je rozwiązuję). Tworzę też pull request do branchu beta. Po sprawdzeniu czy wszystko działa poprawnie na branchu alpha oraz otrzymaniu approve od innych programistów branch jest mergowany do beta. Następnie jeżeli coś ma być na produkcji, to wykonywany jest merge beta do master.
Jednak ostatnio taki flow zawodzi…
1. Jeżeli powstają jakieś konflikty przy mergu do alpha, to na pewno też powstaną konflikty podczas mergowania do beta
2. Czasami dużo nowych branchy jest zmergowane do alpha i później nie jest wiadomo w jakiej kolejności mergować je do beta.
3. W ekstremalnych wypadkach trzeba stworzyć branch z alpha, który i tak ma być później zmergowany do beta, przez co pull requesty mają 2 kilometry.

Mam taki pomysł, żeby to zrobić w taki sposób:
1. Nowy branch z beta
2. Po wykonaniu zadania merge do alpha
3. Pull request do beta
4. Po potwierdzeniu, że wszystko działa poprawnie - rebase z bety, a następnie od razu merge do beta.

Jednak mam pewne obawy czy takie rozwiązanie będzie odporne na losowe mergowanie branchy do beta. Czy trzeba zadbać o odpowiednią kolejność branchy, które będą zmergowane do bety?

#webdev #git #rebase #merge #gitflow

[interface]

@mariecziek: w swoich projektach oss i prywatnych jadę z gitlab-flow, w pracy mamy standardowy git-flow. konflikty to inna bajka, często mam jak merguje do mastera, rzadko jak do fixbrancha

[r.....e]

@mariecziek: albo dziel zadania na mniejsze, albo co jakiś czas sobie rebasuj alpha do featurebrancha

[Wyrewolwerowanyrewolwer]

@mariecziek: W zasadzie to trzeba pamiętać o 2 rzeczach:
1. #!$%@? pozytywnie
2. Najpierw pull, potem push.

Na vidrel dobrze pokazane