[becvvv]

Załóżmy, że mamy taką sytuację:
1. Pracownik A wrzuca mr X do gitlaba
2. Pracownik B rozwiązuje konflikt i akceptuje mr

Czy zamiast tego da się zrobić tak, by to pracownik A rozwiązywał konflikty, a pracownik B tylko akceptował mr? W gitlabie nie widzę takiej opcji.

#programowanie #git #naukaprogramowania #programista15k #gitlab

[tptak]

@becvvv: ustaw tryb merge na fast forward.
To nie rozwiąże konfliktów ale to a odpowiada za gotowość zmiany do wejścia do main.
Ale to dość ostra polityka

[ReduktorGowna]

@tptak: Tak jest. Jak dla mnie git

[becvvv]

@tptak: hmm nie bardzo rozumiem jak w praktyce to wplynie na flow. To teraz jaki tryb jest?

[KORraN]

@becvvv: Też nie rozumiem, przecież jak jest konflikt to pojawia się ikonka i nie można mergować. I to wystawiający MRa powinien ogarnąć, bo bez tego nie ma sensu robić review.

[Saly]

Czy zamiast tego da się zrobić tak, by to pracownik A rozwiązywał konflikty, a pracownik B tylko akceptował mr? W gitlabie nie widzę takiej opcji.

@becvvv: nie rozumiem. Jest konflikt to twórca go rozwiązuje. Tak to działa chyba wszędzie

[becvvv]

@Saly: @KORraN:

Przechodzę na brancha feature/example-feature i Wrzucam MR do brancha test, który polega na tym, że linia:
string test = Foo();

zostaje zamieniona na:
string test2 = Foo();

Okazuje się, że jest konflikt, ponieważ na docelowym branchu jest coś takiego:
string test = Bar();

Nie chcę robić przełożonemu problemu i chciałbym sam rozwiązać ten konflikt. Docelowo powinno być tak:
string test2 = Bar();

Ale jak to zrobić? Mam wejść

[tptak]

@becvvv: gitlab domyślnie robi merge commit, ma jeszcze dwie opcje: chyba ff ze squash i bez squash.
Ff działa tylko wtedy gdy zmiana bazuje na ostatnim commicie w gałęzi docelowej, więc jak są konflikty jakiekolwiek to nie nadaje się do akceptacji

[Saly]

bo stosowany jest gitflow

@becvvv: niestety tu nie pomogę

[tptak]

@becvvv: jeśli pytasz o to kto odpowiada za to aby kod był mergeowalny bez konfliktów to autor zmiany.
Jeśli pytasz jak rozwiązuje się konflikty to są dwie strategie: backmerge z docelowej gałęzi i rozwiązanie konfliktów na tej ze zmianą albo rebase źródłowej gałęzi na końcówkę docelowej i rozwiązanie konfliktów po drodze. Gitlab może też spróbować sam rozwiązać konflikty, jest taki guzik do tego na mr ale nie wiem czy to jest

[tptak]

@Saly: gitflow to strategia przygotowania releasów i nie powinna to niczego zmieniać. Inna sprawa że jej nie lubię i zdecydowanie wolę tylko branch main i wersje w oparciu o tagi, bez zmian w pom/gradle

[Saly]

@tptak: po prostu nie chciało mi się przypominać który branch może się mergować z którym. Normalnie to zrobiłbym rebase do master i elo

[tptak]

@Saly: chciałem to napisać do opa, pardon

[becvvv]

@tptak: @Saly:

Mam wrażenie, że się nie rozumiemy..

Mam branche:
- dev
- test
- staging
- master

Tak wygląda proces dodawania nowej funkcjonalności:

- Ze staginga tworzę nowego brancha:
git checkout staging
git checkout -b feature/example-feature
...
... wprowadzam zmiany
...
git commit -m 'done'

- Merguje zmiany do deva
git checkout dev
git merge feature/example-feature

- Wszystko jest ok, wiec merguje zmiany do test
git checkout test
git

[tptak]

@becvvv: zgubiłeś mnie w połowie, rzeczywiście się nie zrozumieliśmy.


Rozwiązanie 1 jest podstawową praktyką rozwiązywania konfliktów. Ktoś Ci powiedział że tak nie wolno czy Ty to wymyśliłeś?

[Saly]

całe szczęście, że los uchronił mnie od pracy z git-flow

[Dolanthesniffer]

@becvvv: Nie możesz choćby odbić brancha od feature, domergować tam test i rozwiazać konflikt? Jeśli test to jakiś CI, gdzie leżą potencjalnie psujące zmiany, to powinno mu być wszystko jedno co do niego wejdzie, choć to byłaby najgłupsza konfiguracja jaką widziałem.

[becvvv]

@tptak: taki mamy git flow w robocie. Niedawno dołączyłem do zespołu

[becvvv]

@Dolanthesniffer: no nie mogę. Wychodzić można tylko z staginga lub czyjegoś brancha, a nie z dev czy test

[j.....0]

@becvvv po pierwsze, o takie rzeczy powinieneś pytać u siebie w robocie, a nie na wykopie. Po drugie, jeśli mergujesz coś do jakiegoś brancha to logicznym jest, że reszta kodu musi się pokrywać z tym co na tym branchu aktualnie się znajduje. No dobra, możesz też całkowicie wywalić dotychczasowy kod z brancha test, ale chyba nie o pozbywanie się innych zmian tutaj chodzi.