Witajcie.
Jestem początkującym devem i mam mały kłopot z GITem. Mam repozytorium składające się z:
Domyślnie mergujemy do testa. Potem jak wszystko jest ok, to idzie merge na develop, następnie z developa na pre i produkcję.
Zdarzają mi się czasami konflikty na "teście".
W jaki sposób je najlepiej rozwiązać?
Kod na teście i devie jest różny....
Możecie podpowiedzieć? :)
jak nie chcesz mieć konfliktów, to:
Kod na teście i devie jest różny....
To brzmi, jakbyście mieli za dużo gałęzi w tym Gicie i sami sobie utrudniali pracę dzieląc projekt na gałęzie, podczas gdy w waszym stylu pracy to podejście by się nie sprawdzało.
Aplikacja jest leciwa i pliki są faktycznie spore (nawet powyżej 2000 lini).
Różnica w kodzie pomiędzy testem a devem wynika z tego, że testerzy testują i wybierają zadania. Potem nie wszystkie zadania lecą na deva od razu....
Merge mogę zrobić dopiero, jak tester przechodzi do testów - więc tutaj różnie bywa....
https://docs.gitlab.com/ee/user/project/merge_requests/conflicts.html#resolve-conflicts-from-the-command-line
jak "wybucha" konflikt, to jakbyś go rozwiązał w tym przypadku?
git switch id-zadania
git fetch
git rebase origin/develop?
jak "wybucha" konflikt, to jakbyś go rozwiązał w tym przypadku?
To jeszcze nie jest „przypadek” — a w każdym razie, nie jest wystarczająco dobrze i konkretnie opisany przypadek, żeby można było coś sensownie radzić… Konflikty scaleń się biorą stąd, że scalana treść jest właśnie zbyt różna, żeby automat „czuł się” pewnie — stąd potrzeba interwencji użytkownika. Nie można zastąpić jednego automatu innym „automatem”, tylko realizowanym przez człowieka.
Czasem wystarcza „a weź olej to, co było i weź mi to z mojej gałęzi” — strategia „ours”, używana git merge -s ours …. Czasem chce się przełączyć strategię na „recursive” i użyć innego algorytmu do diffów (np. przełączyć się z domyślnego Myersa na histogram lub z powrotem)¹. A może jest taka sieka, że nas nic nie uratuje i trzeba się wycofać i pozmieniać coś ręcznie.
¹ Przede wszystkim dlatego, żeby było lepiej widać zmiany; nie wyręczy nas to raczej.
nie bardzo rozumiem pytanie - jak jest konflikt to znaczy, że przynajmniej dwie osoby zmieniały ten sam obszar pliku. Czasami może to być nawet dodanie nowego kodu w tym samym miejscu, niekoniecznie musi to być zmiana starego. Jak jest konflikt to trzeba go rozwiązać i tyle. Aby to zrobić dobrze jest mieć jakieś narzędzie, które pokaże Ci kod z jedną i drugą zmianą oraz wynik merga (3-way merge) i pozwoli na ręczne poprawki. Nie jest to czarna magia i się zdarza, szczególnie jeśli taski operują w tym samym miejscu kodu.
Lepiej unikać konfliktów w Gicie, niż je rozwiązywać.
Konflikty czasami mogą się zdarzyć, ale jak są nagminnie, to coś jest nie halo i należałoby rozwiązać głębszy problem z tym, w jaki sposób zespół korzysta z gita i jak wygląda codebase.
Różnica w kodzie pomiędzy testem a devem wynika z tego, że testerzy testują i wybierają zadania. Potem nie wszystkie zadania lecą na deva od razu....
Merge mogę zrobić dopiero, jak tester przechodzi do testów - więc tutaj różnie bywa....
A zanim przejdzie do testów, to co robi? Obija się? Ale samo obijanie się nie powinno spowodować konfliktu Gita XD
Poczytaj o trunk based development, który jest polecany nawet przez twórców podejścia używanego przez ciebie (gitflow https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow ). Przy gitflow konflikty są chlebem powszednim i według mnie szkoda życia na ich rozwiązywanie.
Jakie są różnice? W GitFlow masz określone branche na każdy use case (produkcja, testowanie itd) w trunk based masz jednego mastera i tyle. Jak chcesz coś wydać/przetestować to robisz nowego brancha z mastera, jak się coś popsuło to wrzucasz zmianę na mastera i powtarzasz.
mopper napisał(a):
Domyślnie mergujemy do testa. Potem jak wszystko jest ok, to idzie merge na develop, następnie z developa na pre i produkcję.
To są nazwy gałęzi czy środowisk?
Zdarzają mi się czasami konflikty na "teście".
W jaki sposób je najlepiej rozwiązać?
Tak, aby zachować najbardziej aktualną wersję kodu, która przechodzi wszystkie testy.
Pracujemy na GitLab + phpstorm.
Mamy gałęzie:
Zaczynam nowego taska:
Jak wspomniałem wcześniej, projekt jest staaaary i zawiera długie pliki z kodem. Często ludzie się nadpisują.
Na gitlabie tworzy się automatycznie Mr dla TEST i DEVELOPA.
Gitlab proponuje rozwiązanie lokalne i czasami zdalne. Mamy nakaz rozwiązywania lokalnego takich konfliktów....
Jak poprawnie się do tego zabrać?
Phpstorm poprawnie "wypchnął" kod do gita i na ten moment "nie widzi" konfliktu.....
Jak byście się zabrali do takiego przypadku? :)
Dziękuje za pomoc :)
develop jak najczęściej.Komuś się chyba pomyliły gałęzie ze środowiskami. Gorzej, jeśli zrobił to celowo, bo to jakaś mocna perwersja.
Zależy jak często zdarzają się te konflikty. Miałem niedawno taki przypadek, że konflikty zdarzały się nagminnie.
Moim zdaniem przyczyną jest złe zarządzanie projektem. Zresztą to nie był jedyny problem tamtego projektu.
mopper napisał(a):
Jak wspomniałem wcześniej, projekt jest staaaary i zawiera długie pliki z kodem. Często ludzie się nadpisują.
No dobra, kod produkcyjny zawiera długie pliki z kodem. Ale co mają testy do tego? Robiąc testy po fakcie nie trzeba ruszać produkcji. Chyba, że to jakieś TDD, gdzie się pisze jednocześnie testy i implementację, ale z tego, co piszesz, to wyobrażam sobie, że żadnego TDD nie ma testerzy piszą po prostu nowe testy do już wcześniej napisanego kodu. Czemu więc w ogóle ruszają produkcję? Nie mogą stworzyć sobie kolejnych plików robiąc kolejne testy?
Chyba wyraziłem się nieprecyzyjnie :)
Programiści robią Mrki, które są wgrywane w różnej kolejności na TEST. Potem tester siada i testuje. Jeśli znajdzie błąd, to programista poprawia, a tester bierze się za kolejne zadanie.
Po poprawce wgrywany jest kolejny commit. Raz w tygodniu robiony jest merge z Mrek "developowych". Czyli jest spory rozjazd pomiędzy fizycznym kodem na serwerze testowym i serwerze developerskim.
Mój problem poleca na rozwiązaniu konfliktu na TEŚCIE. PHP Storm nie "widzi" błędu. Zmieniając coś w kodzie, zmiana idzie od razu na test i develop.
Co mam zrobić żeby zmienić tylko test?
Potem tester siada i testuje. Jeśli znajdzie błąd, to programista poprawia, a tester bierze się za kolejne zadanie.
(...) Raz w tygodniu robiony jest merge z Mrek "developowych". Czyli jest spory rozjazd pomiędzy fizycznym kodem na serwerze testowym i serwerze developerskim.
Raz w tygodniu - może w tym jest problem. Nie można tego merdżować od razu? Po co czekać tydzień?
Mamy klasy które mają po 7-8 tyś linijek kodu.
To też stopniowo można wydzielać. Nie od razu, ale powoli, tutaj wydzielić jakiś helper do nowego pliku itp. Tak, żeby dążyć do sytuacji, żeby z 8 tysięcy linijek zrobiło się np. 6 tysięcy i pozostałe 2 tysięcy porozdzielane na różne pliki itp. Nie trzeba robić drastycznych zmian od razu, ale powoli, kropla drąży skałę.
Trzeba by było zadać sobie pytanie ile % czasu pracy zajmuje rozwiązywanie konfliktów w commitach i jak często jeden fix powoduje inny bug. Jeśli te wskaźniki są relatywnie wysokie, to pewnie przydałby się gruby refactor. Menedżment może jednak uznać, że refactor będzie za drogi, i że borykanie się z konfliktami jest najbardziej optymalnym rozwiązaniem.
Pytanie też, które konkretnie miejsca w tych dużych plikach są najczęściej ruszane.
Nie jestem pewien jak to sprawdzić (może należałoby poszukać opcji pokazywania hot spotów w jakichś narzędziach GUI do Gita i code review), ale jeśli by się udało ustalić, które miejsca są najbardziej bugogenne czy najcześciej modyfikowane, to już by to była jakaś wskazówka. Może te kawałki kodu trzeba byłoby własnie zrefaktorować albo podzielić na ileś części.
Duże pliki to na pewno problem. Ale mnogość gałęzi jest moim zdaniem bardziej szkodliwa - im ich więcej, tym więcej merdżowania trzeba, i tym większe szanse na konflikty po drodze.
Dlaczego jedna gałąź nie może trafiać po kolei na różne środowiska?