Nowy programista nie może nadążyć za połączeniami oddziałów

222

Jestem nowym programistą - to moja pierwsza pozycja programistyczna.

Mój problem jest następujący: używamy git- wycinam gałąź z naszego developoddziału, a następnie zaczynam pracę nad drobnym zadaniem, które mi przydzielono. Jest bardzo wolny, ponieważ jestem niedoświadczony. Do czasu, gdy jestem gotów połączyć moją gałąź z powrotem, developinni wprowadzili tak wiele zmian, że rozwiązywanie konfliktów jest przytłaczające (w rzeczywistości wydaje się, że łatwiej jest skrobać moją pracę i zacząć od nowa od zadania, co oczywiście nie jest trwałym rozwiązaniem ).

Jak temu zaradzić? Czy mogę zastosować inną taktykę niż „być lepszym w kodowaniu”? Mam zamiar porozmawiać o tym z moim przełożonym w przyszłym tygodniu.

git software branching merging stokrotka
źródło
165
nie musisz scalać swojego oddziału tylko z końcem. możesz scalić rozwijanie w gałąź funkcji stopniowo, kiedy chcesz, aby zmniejszyć ostateczne scalanie.
DavidB
16
Upewnij się, że poprawnie wykonujesz proces scalania. Wpływa to tylko na twoje pliki i tylko twoje zmiany powinny być zastosowane do gałęzi deweloperów. Jeśli występują przypadkowe konflikty, istnieje prawdopodobieństwo, że połączenie zostało wykonane nieprawidłowo lub inni popsuli kolejność zmian. To dobra okazja, aby nauczyć się siebie i być może innych w zakresie łączenia się. Niektórym trudno jest zrozumieć zmiany, a nie scalane pliki. Tak więc wersje zamawiane bez synchronizacji spowodowałyby konflikty w plikach, których nigdy nie dotknąłeś.
16
Upewnij się także, że Twój edytor jest ustawiony poprawnie. Czasami redaktorzy „naprawiają” tabulatory i spacje, więc kiedy edytujesz plik i próbujesz zatwierdzić z powrotem, zmienia on cały plik. Przed zatwierdzeniem powinieneś upewnić się, że tylko zmiany są zatwierdzane w oddziale i naprawić edytor.
32
Jest tutaj jedna dziwna rzecz: „Zaczynam pracę nad drobnym zadaniem” i mnóstwo konfliktów scalania zwykle się nie zgadza. Właśnie połączyłem 2-tygodniową główną gałąź aktualizacji z eksperymentalnym opracowaniem i mieliśmy 10 (!) Konfliktów, których nie można było rozwiązać automatycznie. Nie pojawia się mnóstwo konfliktów, chyba że Twoim zadaniem jest „zmiana nazw zmiennych we wszystkich plikach”. Nie dla MNIEJSZYCH zadań.
TomTom
50
Obowiązkowe xkcd: xkcd.com/1597
ED

Odpowiedzi:

5

Występują konflikty scalania, jeśli zmiany, które wprowadziłeś w oddziale, są zbliżone do zmian develop, które w międzyczasie dokonali Twoi koledzy w oddziale, to znaczy, jeśli ty i twoi koledzy zmieniliście te same wiersze kodu lub sąsiednie wiersze w tym samym pliku.

Aby zmniejszyć prawdopodobieństwo konfliktu scalenia, możesz spróbować scalić wcześniej, aby koledzy zmienili w międzyczasie mniej wierszy lub możesz spróbować zmienić mniej wierszy samodzielnie.

Aby samodzielnie zmienić mniej wierszy, pamiętaj, aby wprowadzać tylko zmiany związane z zadaniem.

Jeśli chcesz eksperymentować na różne sposoby, aby osiągnąć swój cel, może niektóre z eksperymentów zmieniły linie, których tak naprawdę nie trzeba zmieniać? Cofnij te zmiany przed scaleniem.

Istnieje również kilka poleceń Git, które mogą pomóc Ci zmienić tak mało wierszy, jak to możliwe:

  • git diffi git diff --stagedzobaczyć, które linie zmieniłeś.
  • git add -p aby dodać tylko niektóre zmiany w pliku.
  • git commit --amendi git rebase -ido poprawiania zobowiązań, które już wykonałeś w lokalnym oddziale funkcji, zanim przekażesz je do innych repozytoriów Git.

(Zmiana w kilka wierszy jak to możliwe, może również ułatwić recenzję pracę lub korzystać z narzędzi, które działają na różnicach pomiędzy popełnia takie jak git cherry-pick, git rebase, git bisect, i git blame).

Ale nawet jeśli zmniejszysz prawdopodobieństwo konfliktu scalania, nadal będziesz czasem napotykać konflikty scalania. Nie bój się ich, ale naucz się rozwiązywać konflikty.

Toxaris
źródło
1
Również przed scaleniem, git fetcha git diff origin/developwyświetli podgląd połączenia (w pewnym sensie). Daje szansę wyczyścić zmiany, zanim pojawi się mnóstwo bezcelowych konfliktów.
Maks.
288

Zakładam, że używasz gita. Jeśli tak, skorzystaj z git rebase -i( -iśrodki interaktywne). Spraw, aby codzienne zadanie (jeszcze częściej, jeśli to konieczne) bazowanie gałęzi na gałęzi deweloperskiej. Powoduje to stopniowe wprowadzanie zmian każdego dnia (przynajmniej), aby utrzymać aktualną gałąź funkcji. Jeśli podczas codziennego naliczania występują konflikty, musisz porozmawiać z zespołem o tym, kto nad czym pracuje.

Jeśli uruchamiasz go codziennie, prawdopodobnie nie będziesz potrzebować części interaktywnej. Po prostu pozwól mu to zrobić.

Jestem dość doświadczonym programistą i wciąż zajmuje mi sporo czasu, aby przyśpieszyć nowy projekt. W twoim przypadku wygląda na to, że kilka osób pracuje jednocześnie nad tym samym projektem, więc jest to albo bardzo duży projekt, albo nowy projekt, który ewoluuje szybko. W obu przypadkach nie przejmuj się, jeśli przejście do obiegu zajmie Ci kilka miesięcy . Jeśli zmienię projekty na 2 lub 3 tygodnie, a następnie przestawię z powrotem, może minąć kilka godzin (a nawet dzień lub dwa), aby w pełni „wrócić do” projektu, który napisałem sam w 100%!

Krótko mówiąc, nie martw się, że jesteś teraz powolny. Sposobem na poprawę jest po prostu ćwiczyć. Nie bój się pytać innych programistów o aspekty projektów, których nie rozumiesz.

EDYTOWAĆ:

Lub użyj merge. To także opcja. Tak więc powyższe byłoby: „skorzystaj z git rebase -i( -iśrodki interaktywne) lub git merge”. Jeśli chodzi o to, którego użyć, porozmawiaj o tym z resztą swojego zespołu. W obu przypadkach mogą (ale nie muszą) mieć silne preferencje. To jasne, niektórzy ludzie nie mają silne preferencje.

Jacob Robbins
źródło
22
Myślę, że to poprawna odpowiedź, ale IMO to kolejny przykład złego projektu i terminologii Git. Co ty „odpuszczasz”? Czy nie powinno się to nazywać „aktualizacja”, „kasa”, „scalanie” czy coś takiego ??? (Odpowiedź poniżej uzasadnia „pobieranie”) Jaki jest sens kontroli kodu źródłowego, jeśli każdego dnia musisz aktualizować ???
user949300
95
Nie aktualizuje się ani nie sprawdza. Pobiera wszystko, co znajduje się wyłącznie w twojej gałęzi i dodaje zmiany tak, jakbyś właśnie wprowadził je w innej gałęzi. To znaczy, że twoje zmiany są teraz „oparte na” drugiej gałęzi. Co więcej, nie istnieje żaden magiczny system kontroli źródła, który zna Twój kod i może wiedzieć, jak scalać zmiany, gdy wiele osób modyfikuje te same pliki. Aktualizujesz codziennie, aby konflikty były małe i łatwe do zarządzania, a zmiany były świeże w głowach wszystkich, aby wiedzieli, jak sobie z nimi poradzić.
Vectorjohn
54
Zmiana użytkownika @ user949300 różni się od łączenia, jest znacznie bardziej dopracowana i wymaga lepszego zrozumienia Git niż zwykłego przepływu pracy scalania. Dlatego nigdy nie polecam przepływu pracy polegającego na zmianie bazy na początkującego Gita, ponieważ prowadzi to do założenia, że ​​zmiana jest jedynym / domyślnym sposobem aktualizacji gałęzi i prowadzi do wielu niepotrzebnych pułapek i bólu. W takim przypadku scalenie rozwiąże problem w ten sam sposób i nie rozwiąże problemu konfliktu scalania w dwóch długo działających równoległych gałęziach funkcji.
Ant P
14
@ user949300, git pullktóry jest tylko kombinacją git fetchi git merge(lub możesz dodać, --rebaseaby wykonać rebase zamiast scalenia). Zakładając, że masz tylko jeden dzień opóźnienia, to w sieci LAN prawdopodobnie zakończy się to w niecałą sekundę, może to potrwać kilka sekund przez Internet. Nawet przez Internet i przy niewielkich konfliktach scalania możesz być na bieżąco i bezproblemowo połączyć się w mniej niż minutę. Poświęcenie pięciu minut na cały tydzień jest o wiele lepsze niż spędzanie godziny pod koniec tygodnia na poważnym konflikcie scalania.
Derek Elkins,
66
Nie mam głosowania, ponieważ ta odpowiedź jest całkowicie naprawiona podczas zmiany bazy. Rebasing może być użytecznym narzędziem, ale nigdy nie należy go używać bezmyślnie. Do codziennej aktualizacji lepiej połączyć. Dlaczego? Ponieważ każda baza jest kłamstwem . Opowiadasz historię w sposób, w jaki nigdy się nie wydarzyła. Może to całkowicie zepsuć potężne narzędzia, takie jak git bisect: Wycofane elementy mogą nawet się nie kompilować, więc nie git bisectmają znaczenia dla wynikowych złamanych zmian. @maaartinus: Ja, na przykład, wolę prawdziwą historię od historii liniowej. Jeśli dokonasz zmiany, absolutnie musisz sprawdzić każdy nowy zatwierdzenie pod kątem zdrowia psychicznego, aby uniknąć szkodliwych kłamstw.
cmaster
131

Może to być oznaką złej inżynierii oprogramowania ze strony firmy. Zbyt wiele zależności, różne problemy z nakładającymi się funkcjami, próby rozwiązania problemów w niewłaściwej kolejności itp. Mogą spowodować opisaną sytuację. Sugeruję regularne łączenie developsię z twoim oddziałem podczas programowania

Iwan Anatoliewicz
źródło
9
To koduje 101 rzeczy, jak wspomniałeś. Niekoniecznie dokładna refleksja na temat nowego pracownika.
Mister Positive
2
@Ivan Anatolievich OP mówi, że są oni rozgałęzieni w rozwoju, a nie mistrzu, FYI
Matthew
6
Ta odpowiedź pokazuje dokładnie, dlaczego nie lubię GIT: to kolejne narzędzie dla zespołów, aby uniknąć właściwego zarządzania i przyzwoitego planowania. Odpowiedź na wszystko brzmi: „kogo to obchodzi, zawsze możesz użyć tego polecenia później”, zamiast unikać problemów, zanim się pojawią.
motoDrizzt,
7
moja pierwsza myśl była również oznaką złych praktyk, deweloperzy nie powinni w większości pracować nad tymi samymi plikami. Jeśli mały projekt ma tak wiele konfliktów, wszyscy inni muszą po prostu rozwiązywać konflikty przez cały dzień, nie wykonując żadnej pracy!
Aequitas
14
@motoDrizzt What? Nigdy nie słyszałem, aby ktokolwiek argumentował.
jpmc26,
95

Uważam, że zaakceptowane odpowiedzi są bardziej technicznym „sposobem korzystania z Git lepiej”, myślę, że jest to raczej problem zespołowy niż problem inżynieryjny lub narzędziowy.

Jeśli napotykasz wiele konfliktów scalania, oznacza to, że ty i ktoś inny w zespole stąpacie po sobie nawzajem.
Ty lub oni powinniście starać się rozwijać osobistą przestrzeń podczas kodowania i unikać pracy w obszarach, które są już zajęte.

W moim zespole dążymy do wysokiego stopnia odpowiedzialności za zadania.
Zwykle przejmuję pełną lub całkowitą własność dwóch lub trzech plików jednocześnie i pracuję nad nimi w oddziale przez co najmniej jeden dzień.
Zazwyczaj, jeśli ktoś dotknie tych plików, jest to absolutnie konieczne do ich własnych zadań, generalnie nie pracujemy razem nad tym samym blokiem zadań!

Jeśli okaże się, że musisz w ogóle dużo scalić, to albo cały kod twojego zespołu znajduje się w jednym miejscu (czego sam w sobie należy unikać), albo wszystkie twoje zadania są.

To powiedziawszy, jako nowy deweloper prawdopodobnie nie jesteś w stanie egzekwować, prosić, a nawet sugerować jakiejkolwiek restrukturyzacji.
Spodziewam się, że twoje zadania zostały przypisane jako rzeczy „do nauczenia się lin”, które powinny być rozsądnie dostępne na twoim poziomie umiejętności, aby ułatwić ci dołączenie do zespołu. Prawdopodobnie zostali zwolnieni z zadań współpracownika, który nadal pracuje w tym samym obszarze, stąd wasze konflikty scalania.
Rozwiązaniem tego jest rozwiązanie problemu, rozwiązanie problemów, radzenie sobie z konfliktami scalania najlepiej jak potrafisz i nie martw się zbytnio, o ile robisz wszystko, co w twojej mocy, to menedżer musi się martwić Twój postęp.
Z biegiem czasu będziesz coraz szybszy i bardziej pewny siebie,

Jarzębina
źródło
4
Myślę, że trafiłeś w sedno konfliktem współpracowników. Konflikty scalania są normalną rzeczą, ale zazwyczaj ograniczają się do kilku plików.
Matthieu M.,
10
Brzmi to jak następstwo Prawa Conwaya i zasady Pojedynczej odpowiedzialności - tzn. Jeśli ludzie pracują nad różnymi problemami, wówczas najlepiej będą edytować oddzielne części kodu źródłowego.
ChrisW,
7
Chociaż zgadzam się, że zły proces lub zły projekt mogą prowadzić do dużej liczby konfliktów, jestem całkiem pewien, że problemem jest po prostu to, że OP nie łączy się regularnie z linią główną. Nie zgadzam się, że „przejęcie pełnej i pełnej własności” plików jest oczywiście właściwe. Nie chcę, aby mój zespół stale narzucał, kto „jest właścicielem” tego, co teraz, prosi „pozwolenie” na dokonanie zmian lub zgaduje, jakie pliki powinien „zgłosić”. Rzadko, kiedy znacznie przepisuję komponent, prosiłem członków zespołu o informację, czy zamierzają zmienić niektóre pliki.
Derek Elkins,
1
ChrisW ma dobry pomysł z tym, na czym jechałem. Ogólnie rzecz biorąc, własność w mojej firmie ma formę funkcjonalności aplikacji, przejmuję całkowitą własność systemu Search Filter jako zadanie i jak się zdarza, nikt inny nie musi dotykać powiązanych plików w większości przypadków. Mam wrażenie, że jest bardzo prawdopodobne, że OP jako nowy starter otrzymał niewielkie części zadań ściśle związanych z bieżącym zestawem zadań przez innego twórcę. Oznacza to, że drugi deweloper pracuje w tej samej części bazy kodu i wzajemnie sobie przeszkadzają.
Rowan,
1
@Rowan Cool tak, myślałem tak samo. Separacja funkcjonalna może również pomóc w separacji plików (zestawy funkcji w różnych plikach itp.), A to IMO pomaga w scalaniu.
SaltySub2
28

Najważniejszą rzeczą w łączeniu jest to, że im dłużej czekasz, tym bardziej bolesne staje się. Problem staje się bardziej liniowy. Trzy razy więcej konfliktów to dziewięć razy więcej pracy. Istnieje kilka strategii:

Łącz się z gałęzią programistyczną za każdym razem, gdy się zmienia, dzięki czemu zawsze jesteś blisko i nigdy nie masz ogromnej liczby konfliktów.

Jeśli zabierasz dużo czasu, przyczyną może być to, że spędzasz większość czasu na zastanawianiu się, jakie są zmiany, a następnie na wprowadzeniu zmian. W takim przypadku należy połączyć się z gałęzią programistyczną przed rozpoczęciem rzeczywistych zmian kodu.

Porozmawiaj z kolegami na temat strategii unikania konfliktów. Występują konflikty, jeśli dwie osoby edytują ten sam kod. Nie tylko ten sam plik, ale ten sam kod. Potrzebuję więc nowej funkcji functionA, a ty potrzebujesz nowej funkcji functionB, i oboje dodajemy ją na końcu tego samego pliku, mamy konflikt. Jeśli dodamy go w różnych miejscach, nie będzie konfliktu. Jeśli oboje dodamy go w miejscu pliku, do którego logicznie należy, istnieje prawdopodobieństwo, że nie będziemy mieć konfliktu.

Jeśli masz konflikty, zdobądź dobre narzędzie do porównywania, abyś mógł porównać gałąź rozwoju przed scaleniem, kod przed scaleniem, kod oryginalny i scalony i scalić ręcznie.

W najgorszym przypadku: nie wyrzucasz swojej pracy, ale używasz dobrego narzędzia do porównywania, aby dowiedzieć się dokładnie, jakie zmiany dokonałeś, ponownie uruchomić programowanie i zastosować wszystkie zmiany, które wprowadziłeś ręcznie, zamiast ich ponownego wpisywania.

gnasher729
źródło
Gałęzie funkcji prezentują się jak inna forma długu technologicznego, w którym zmiany up-streamingu z gałęzi macierzystej są jak refaktoryzacja.
Dan Lyons,
Z wyjątkiem, że mają zapłacić długu. Teraz.
gnasher729,
15

Do czasu, gdy będę gotowy ponownie połączyć moją gałąź w celu rozwoju (moje podkreślenie)

Rozwiązywanie konfliktów git mergejest często łatwiejsze niż w git rebase. W Git Merge możesz zobaczyć całą listę plików, które zostały zmodyfikowane jednocześnie. Bez względu na to, ile zobowiązań wykonali inni współpracownicy, będziesz musiał połączyć się raz . Dzięki przepływowi pracy w bazie danych może się zdarzać, że ciągle pojawiają się te same konflikty i trzeba je przeglądać ręcznie. Możesz w końcu naprawić 13. zatwierdzenie i czuć, że nie widzisz światła z tunelu .

Z mojego doświadczenia wynika, że ​​gdy próbowałem naiwnie rozwiązywać powtarzające się konflikty bazy, straciłem czyjeś modyfikacje lub aplikację, która nawet się nie skompilowała. Często ja i współpracownicy wykonaliśmy wiele pracy, ale ogarnęło mnie tak duże skomplikowanie powtarzających się konfliktów, że musieliśmy przerwać i stracić naszą poprzednią pracę po kilku zobowiązaniach dotyczących rebase.

Mam zamiar zasugerować kilka technik, ale mogą one tylko ułatwić łączenie niż zautomatyzować zadanie.

  • Pliki zasobów / języka . Jeśli masz zmiany addytywne w pliku zasobów, upewnij się, że zawsze przenosisz je na koniec pliku, abyś mógł łatwo przywołać swoje zmiany w porównaniu ze zmianami innych . Możesz skopiować i wkleić zmiany na dole lub po prostu usunąć znaczniki konfliktu
  • Zrobić. Nie. ABSOLUTNIE. RE-formatu . Ani Ty, ani Twoi koledzy deweloperzy nie powinni wykonywać „ogromnego formatowania kodu” podczas codziennej pracy. Formatowanie kodu dodaje nadmierną liczbę fałszywych alarmów w zarządzaniu konfliktami. Formatowanie kodu można wykonać
    • Stopniowo, np. Przez każdego programistę przy każdym zatwierdzeniu, gdy tylko użyją zautomatyzowanego narzędzia (np. Eclipse ma opcję ponownego sformatowania przy zapisie, waniliowe Visual Studio nie ma żadnego). Absolutnie każdy programista musi stosować te same standardy formatowania kodu, zakodowane w pliku formatu, który jest spożywany przez twoje IDE. Aby dać ci wyobrażenie, jeśli są to 4 spacje lub 2 tabulatory, nie ma to znaczenia, ale naprawdę ma znaczenie, jeśli wszyscy używają tego samego.
    • Tuż przed wydaniem przez lidera zespołu. Jeśli zatwierdzenie „formatowania kodu” nastąpi, gdy ludzie nie pracują na gałęziach, tj. Przed rozgałęzieniem, rzeczy będą łatwiejsze
  • Przejrzyj podział pracy między współpracowników. Ten jest częścią, z której pochodzi większość inżynierii. Jak wskazują inne odpowiedzi, to zapach projektu, gdy wielu programistów wykonujących różne zadania musi dotknąć tych samych zasobów. Być może będziesz musiał porozmawiać z liderem zespołu o tym, jaką część ma modyfikować każdy współbieżny programista.

Zauważyłem również złe nawyki w przepływach pracy Git w moich zespołach. Często ludzie nadmiernie angażują się w swoje oddziały. Osobiście byłem świadkiem, jak programista dodaje 10 do 20 zatwierdzeń oznaczonych jako „fix”, z których każdy zatwierdza jedną lub dwie linie. Zgodnie z naszymi zasadami zatwierdzenia są oznaczone biletami JIRA, aby dać Ci pomysł.

@JobobRobbins sugeruje wykonanie git rebasecodziennego zadania. Chciałbym przyspieszyć jego podejście.

Najpierw użyj raz bazy, aby zmniejszyć liczbę zatwierdzeń do garstki. I bazuj tylko na oryginalnej gałęzi developerskiej, która jest zatwierdzeniem, z którego rozgałęziłeś się. Kiedy mówię garstkę, mógłbym mieć na myśli 3 lub 4 (np. Cały interfejs, wszystkie zaplecze, wszystkie łatki do baz danych) lub dowolną ludzką rację. Po ich konsolidacji użyj fetchi przeprowadź rebase w gałęzi upstream. To nie uchroni cię przed konfliktem, chyba że Twój zespół dokona przeglądu własnego podejścia, ale sprawi, że twoje życie będzie mniej bolesne.

Jeśli masz dodatkowe pytania na temat konkretnych zadań, przeszukaj i zapytaj w Stackoverflow.

[Edytuj] na temat zasady braku reformatowania i zwiadowców. Lekko przeformułowałem format RE, aby podkreślić, że mam na myśli zadanie formatowania od zera całego pliku źródłowego, w tym kodu, którego nie dotknąłeś. W przeciwieństwie do tego, aby zawsze formatować własny kod, który jest całkowicie nieprzyzwoity, wielu programistów, w tym ja, jest używanych do przeformatowania całego pliku za pomocą możliwości IDE. Gdy inni dotkną pliku, nawet jeśli zmienione linie i semantyka nie zostaną zmienione, Git uzna go za konflikt. Tylko bardzo potężny edytor rozpoznający język może sugerować, że konflikt dotyczy tylko formatowania i automatycznego scalania najlepiej sformatowanego fragmentu. Ale nie mam dowodów na istnienie takiego narzędzia.

W końcu zasada zwiadowcy nie nakazuje ci sprzątać bałaganu innych ludzi. Tylko twój.

usr-local-ΕΨΗΕΛΩΝ
źródło
3
Jest to w dużej mierze kwestia opinii, ale nie zgadzam się, że łatwiej jest poradzić sobie z konfliktami scalania niż konfliktami bazowymi. Podczas zmiany bazy zasadniczo stosujesz zatwierdzenia jeden po drugim, dzięki czemu zakres konfliktów scalania jest znacznie mniejszy i łatwiejszy do naśladowania (stosujesz SWOJE zmiany, które znasz - a nie zmiany innych osób, których nie znasz). W ten sposób może być konieczne rozwiązanie większej liczby konfliktów scalania (z powodu wielokrotnego dotykania tych samych plików między zatwierdzeniami), ale będą one mniejsze i łatwiejsze do rozwiązania.
user622505,
3
Jeśli chodzi o formatowanie, VS nie może tego zrobić automatycznie po zapisaniu, jeśli ustawisz „Kiedy wklejam” na „Wcięcie i formatowanie” w „Narzędzia” -> „Opcje” -> „Edytor tekstu” -> „< Twój wybrany język> „->„ Formatowanie ”, co oznacza, że ​​formatuje się automatycznie po wklejeniu. Pozwala to na sekwencję trzech naciśnięć klawiszy: ctrl-A, ctrl-C, ctrl-V, aby uzyskać pożądany rezultat. To powiedziawszy, +1 za Do. Nie. ABSOLUTNIE. Sformatuj O ile nie zarysujesz w bardzo dokładnie kontrolowanych warunkach.
dgnuff,
1
Czytelnicy Bob Martin powinni pamiętać, że zasada harcerstwa musi być stosowana z powściągliwością, jeśli pracujesz w zespole (jeśli pracujesz na własną rękę, masz znacznie większą elastyczność). Jeśli zinterpretujesz zasadę jako „Moim obowiązkiem jako programisty jest naprawienie dosłownie wszystkiego w każdym pliku, który nie jest idealny w momencie, gdy się o tym dowiem, bez względu na to, nad czym wszyscy inni pracują”. gigantyczna ilość trudnych do rozwiązania konfliktów, i będzie to wielki bałagan, bez względu na to, jak dobre są twoje intencje.
jrh
2
Czujesz potrzebę sformatowania lub lekkiego refaktoryzacji kodu, zrób to przed lub po znaczącym zatwierdzeniu. To nie tylko zmniejszy konflikty, ale także pomoże przyszłemu czytelnikowi twojego zatwierdzenia, w tym recenzentom
max630,
1
Z mojej kultury C # „ponowne formatowanie” oznacza czynność formatowania całego pliku kodu lub nawet całego repozytorium, gdzie formatowanie jest związane tylko z czytelnością . Jeśli twój język używa znaczących białych znaków, nie powinieneś zadzierać z białymi znakami w LOC, które nie są twoje. I odwrotnie, twój wybrany język może nadal dopuszczać nieistotne białe znaki (np. Przed
nawiasami
5

Po pierwsze, nie myśl o odrzuceniu zmian. Stracisz możliwości uczenia się procesu scalania.

Po drugie, znajdź osobę, która pracowała nad plikami powodującymi konflikt. Możesz zobaczyć historię. Porozmawiaj z osobą i rozwiąż konflikty w tych plikach. Zrób to samo w przypadku innych konfliktów.

Jeśli konfliktów jest zbyt wiele, twoje zadanie może być niewielkie, ale powtarzalne. Spróbuj znaleźć wzór. Pomogłoby to rozwiązać konflikty za pomocą narzędzi klienta Git UI. Używam TortoiseGit. Pomaga w łączeniu.

I do unikania w przyszłości,

  • Bardzo dobrą praktyką jest regularne łączenie gałęzi programistycznej z gałęzią funkcji.

  • Jeśli masz włączony CI, sprawdź, czy narzędzie CI zapewnia kompilację gałęzi. Powinno to opierać się na każdym sprawdzeniu dokonanym w gałęzi funkcji, ale po scaleniu rozwijaj gałąź.

PKV
źródło
1
+1 Inne sugestie dotyczące lepszego używania Git są dobre, ale tak naprawdę rozmowa z innymi programistami na temat konfliktów scalania jest kolejnym kluczowym aspektem rozwoju efektywności PO.
Dragonel,
1
„Możesz zobaczyć historię” Może! Zależy, jak wszystko jest zmiażdżone i przekształcone: P
Wyścigi lekkości na orbicie
1

Powinieneś regularnie uruchamiać (codziennie) polecenie „git fetch” (nie git pull) z gałęzi programistycznej. Spowoduje to, że inne osoby dokonają zmian i wprowadzą je do gałęzi funkcji bez próby zintegrowania zmian z gałęzią.

O tym powinieneś porozmawiać z głównym deweloperem (niekoniecznie z kierownikiem), ponieważ Twoja firma może mieć własne standardy lub zalecane sposoby rozwiązania tego problemu; to jest bardzo powszechne. Nie czekaj do następnego tygodnia - dowiedz się teraz o tym procesie i zapytaj, czy możesz wykonać trywialną pracę (taką jak formatowanie kodu lub dodawanie komentarzy), aby przetestować proces.


źródło
21
Nie jestem pewien, czy to prawda. Git sprowadzić dostanie pilotów zdalnego sterowania / pochodzenia / master na bieżąco, ale wtedy trzeba scalić pilotów zdalnego sterowania / pochodzenia / pana do swojego fabularnego oddziału (lub piloty / pochodzenie / rozwijać jeśli to przepływ są przy użyciu)
Richard mrowienie
Zakładając, że używa git, dobrym pomysłem jest nauczenie się, jak zmiażdżyć swoje zobowiązanie do znaczących części. W ten sposób, gdy jesteś gotowy, aby złożyć polecenie ściągnięcia, twoje zatwierdzenie jest uproszczone, proste i łatwe do zrozumienia.
@RichardTingle Prawidłowo, myśli o opcji rebase. Po prostu pobierasz i bazujesz swoją gałąź za pomocą gałęzi deweloperów. To zsynchronizuje wszystko.
6
@ Czy myślę, że może to być kwestia opinii. Osobiście nienawidzę wielkich zobowiązań. Spróbuj podzielić to na części!
Richard Tingle
2
@PeteCon „i przenieś je do swojej gałęzi funkcji, nie próbując zintegrować zmian z gałęzią”. To wydaje się być sprzecznym stwierdzeniem. Myślę, że masz na myśli wprowadzenie ich do lokalnego repozytorium bez zintegrowania ich z gałęzią funkcji, ale nie jestem pewien, jak to pomaga ...
Jason Goemaat
1

Oczywiście przede wszystkim należy unikać pracy wielu osób nad tymi samymi plikami, przynajmniej w sposób, który prowadzi do trudnych konfliktów. Dodawanie rzeczy do wyliczeń nie stanowi problemu, o ile używany jest dobry format kodu. Zmiana przepływu sterowania na różne sposoby i przenoszenie kodu jest znacznie trudniejsze. Czasami jest to jednak nieuniknione. Podczas rozwiązywania naprawdę skomplikowanych konfliktów będziesz musiał zadawać pytania.

To powiedziawszy, widzę wiele odpowiedzi zalecających regularne łączenie / bazowanie. Byłbym o wiele mniej entuzjastycznie nastawiony do tego rodzaju porad. Twoim celem w tym momencie jest uczynienie procesu rozwiązywania konfliktu tak łatwym i bezpiecznym, jak to możliwe. Jedną z rzeczy, która ogromnie pomoże w tym procesie, jest natychmiastowe udostępnienie tylu testów regresji, w tym nowych, które są częścią nowej funkcji. Jeśli bardzo regularnie synchronizujesz swój oddział z programistą, zawsze będziesz musiał rozwiązać konflikty, dopóki nie skończysz w rzeczywistości implementować swojej funkcji. A to oznacza, że ​​trudniej będzie dowiedzieć się, co powinien zrobić kod, ponieważ nie zostało to zrobione. Przed próbą scalenia upewnij się, że twoja gałąź jest spójną jednostką zmian. Nawet lepiej,

Starałem się nie wchodzić w meritum bazowania na scalaniu, co prawdopodobnie dotyczy innego pytania. W tym kontekście narzędzia tak naprawdę nie mają znaczenia.

Kafein
źródło
1

Do czasu, gdy jestem gotów ponownie połączyć mój oddział w rozwój, inni wprowadzili tyle zmian, że rozwiązanie konfliktów jest przytłaczające

Brzmi to jak idealny scenariusz do programowania w parach !

Więcej informacji o korzyściach i podstawowych podejściach:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Z czasem przyspieszysz od pracy na własną rękę, ale może to być zniechęcające, dopóki nie nadejdzie ten czas, a czasem jest to również długa droga. Ponadto, podczas gdy ludzie mogą szybko nauczyć się przebywania w stresującym środowisku, zawsze zmuszeni do nadrobienia zaległości, inni, którzy nie uczą się dobrze pod stałą presją, będą mieli trudności.

Zamiast pracować nad własnym oddziałem i starać się nadążyć za innymi deweloperami, którzy są oczywiście znacznie szybsi od ciebie, zamiast tego pracujesz bezpośrednio (ten sam komputer) z innym deweloperem. W ten sposób otrzymujesz natychmiastowe porady i prawdopodobnie zbierzesz wskazówki, jak przyspieszyć itp.

Wypracowałbyś najlepsze podejście do konkretnego kodu w swoim projekcie, ponieważ programowanie parami nie zawsze ma sens w przypadku niektórych projektów - choć prawdopodobnie zawsze ma sens uczenie się, nawet jeśli po prostu siedzisz i patrzysz na kogoś bardziej doświadczonego niż ty (o ile są dobrym twórcą, doświadczenie niekoniecznie oznacza, że ​​stosują dobre praktyki).

Siedzenie z szybszym, bardziej doświadczonym deweloperem może pomóc:

  • Prawdopodobnie ograniczy konflikty scalania, ponieważ praca z kimś bardziej doświadczonym wydłuży czas ukończenia, w przeciwieństwie do pracy w pojedynkę
  • Będą cię uczyć, prawdopodobnie będą wolniejsi niż pracowaliby sami, więc mogą nadal występować konflikty scalania, a więc mogą one poradzić sobie z kimś wytrawnym, a więc może znaleźć wskazówki dotyczące oszczędzania czasu itp.
  • Pomóż zobaczyć potencjalne sztuczki i sposoby na bycie szybszym (chociaż powolność to czasem po prostu brak doświadczenia, a nie dobrych praktyk)
  • Może natychmiast zadawać pytania, gdy coś nie ma sensu lub nie jest w 100% jasne
  • Praca 1: 1 jest cenna do nauki, ponieważ osoba, od której prosisz o pomoc, już rozumie dokładny kod i scenariusz podczas pracy nad nim, bez programowania w parach musisz wyjaśnić kod i scenariusz, co często kończy się problemem i więc tracicie czas / uwagę na uzyskanie bardzo potrzebnej porady
  • Poznaj proces myślenia kogoś bardziej doświadczonego i doświadczonego, a dzięki dobrej komunikacji z pewnością nauczysz się nowych rzeczy

Czy mogę zastosować inną taktykę niż „być lepszym w kodowaniu”? Mam zamiar porozmawiać o tym z moim przełożonym w przyszłym tygodniu.

Moja rada to omawianie programowania par z innymi programistami, a następnie skontaktowanie się z przełożonym. Jeśli są przyzwoici, docenią twoją inicjatywę, która ma większą szansę na wypromowanie zalet programowania w parach (jeśli tego potrzebują, większość ludzi o tym wie i powszechnie wiadomo, dlaczego to pomaga).

James
źródło
Szczerze, kto przegłosował :( to nie jest jakieś dzikie przypuszczenie, zdarza się to w moim miejscu pracy i udowodniono, że działa! Nawiasem mówiąc, ciężko pracowałem nad innymi odpowiedziami na inne pytania na tej stronie, aby móc mieć 10 powtórzeń (powyżej mojego powiązanego przedstawiciela ), aby móc zasugerować „programowanie parami” w tym, ponieważ nikt tego nie zasugerował. Naprawdę ciężko pracowałem, aby na to odpowiedzieć.
James
1

Tutaj jest kilka podstawowych problemów. Twoje problemy łączenia się najprawdopodobniej nie są twoją winą i częściej są objawem złych praktyk.

1) Idealnie byłoby połączyć swój oddział w rozwój każdego dnia. Postaraj się mieć działający kod przynajmniej raz dziennie, który przejdzie wszystkie testy, abyś mógł się połączyć z programowaniem.

2) Jeśli nie masz działającego kodu w którymkolwiek momencie podczas zwykłego dnia pracy, prawdopodobnie masz zbyt duże fragmenty kodu, aby pracować. Musisz podzielić swoje zadanie na mniejsze zadania, które można ukończyć (najlepiej niezależnie od siebie) szybciej, aby można je było scalić.

3) Twoje pliki projektów są prawdopodobnie zbyt duże. Jeśli istnieje wiele konfliktów scalania dla pliku, zbyt wiele osób pracuje nad jednym plikiem. Idealnie, nad czym jedna osoba pracuje, powinna być oddzielona od tego, nad czym wszyscy inni pracują.

4) Twój zespół może być za duży. Jeśli łatwiej ci wyrzucić całą funkcję i zacząć od nowa, prawdopodobnie zbyt wiele osób popełnia kod do tego samego repozytorium.

5) Być może nie masz spójnych standardów formatowania kodu. Jeśli nie wszyscy konsekwentnie używacie tego samego formatowania kodu, pojawi się wiele różnych konfliktów dla tego samego kodu. W zależności od konfiguracji gita mogą one nawet sprowadzać się do konfliktów białych znaków (zakończenia linii, wcięcia, tabulatory a spacje).

6) Ludzie mogą wypychać swoje zmiany bezpośrednio do działu rozwoju.

Oto, co możesz zrobić: 1) Jeśli nie możesz scalić się z programowaniem każdego dnia, scalaj / rebase rozwijaj się do swojego oddziału codziennie (lub częściej).
2) Spróbuj oddzielić swój kod od kodu każdego innego.
3) Porozmawiaj z resztą zespołu o mniejszych funkcjach, spójnych standardach kodowania i lepszej organizacji kodu (mniejsze pliki, mniejsze funkcje).

xyious
źródło
1

Wydaje się, że łatwiej jest skrobać moją pracę i zacząć od nowa od zadania, co oczywiście nie jest zrównoważonym rozwiązaniem)

Przez większość czasu tak właśnie robię, kiedy po raz pierwszy naprawiam błąd lub wprowadzam zmiany w systemie, uczę się, jak to zrobić. Następnym razem, gdy naprawię ten sam błąd, zajmie to tylko 1% czasu, ponieważ teraz rozumiem problem.

Uważam też, że kiedy robię trochę pracy, piszę lepszy kod .....

Dlatego nie ma nic złego w tworzeniu nowego oddziału od mistrza, ponawianiu pracy w nim, przy użyciu „prywatnego oddziału”, aby przypomnieć ci, co musisz zrobić.

Możliwe jest również, że odkryłeś sposób podziału zmiany na logiczne i poprawne części, z których każda po scaleniu zostaje scalona z gałęzią master. Na przykład można przeprowadzić testy jednostkowe i zmiany w kodzie zaplecza, a następnie scalić je. Następnie w osobnej operacji można wprowadzić zmiany interfejsu użytkownika, które z nich korzystają, a zatem mniejsze jest ryzyko, że ktoś edytuje ten sam plik interfejsu użytkownika.

Ian
źródło
1

Jeśli nie chcesz zbyt często łączyć gałęzi programistycznej z gałęzią, możesz uzyskać przepływ pracy bardziej podobny do svn, używając git pull --rebase. Spowoduje to wyciągnięcie nowych commits i ponowne ich zatwierdzenie. Oznacza to, że kiedy scalisz swoją gałąź w celu rozwoju, będzie to szybkie przewijanie do przodu (tak jakbyś dodał wszystkie swoje poprzednie zatwierdzenia w tym samym czasie jeden po drugim) i nie będzie żadnych konfliktów scalania, ponieważ rozwiązałeś je wszystkie podczas git pull --rebase.

Ale im więcej zobowiązań podejmiesz przed scaleniem gałęzi w rozwijającą się lub rozwijającą się w gałęzi, tym bardziej skomplikowane będzie uzyskanie kolejnego podziału bazy i nieco podważy sens gałęzi cech, ponieważ twoja gałąź istnieje tylko tak długo, jak jest połączona .

allo
źródło
1

Kiedy pracujesz we wspólnych plikach, w żaden sposób ty lub twoi koledzy z drużyny musicie rozwiązać wszystkie konflikty przed połączeniem zakończeń, dlatego nie martw się . Nadal pracujesz nad projektem i bądź dumny ze swojej pracy. Teraz, aby wykonać mądrzejszy ruch, możesz postępować zgodnie z poniższymi sugestiami.

  1. Podziel zadania niezależnie:

    Przed rozpoczęciem pracy zaplanuj i podziel całe zadania w taki sposób, aby przydzielone zadanie dla każdego członka zespołu było jak najbardziej niezależne i modułowe (aby uniknąć potencjalnych konfliktów podczas opracowywania). Możesz podejść do swojego lidera scrum, aby przypisać ci pewne niezależne zadania, gdy jesteś początkujący.

  2. Scalanie szczegółowych zatwierdzeń częstych:

    Nie czekaj na ukończenie pełnego zadania przed końcowym marge. Oczywiście wszelkie większe zadania można podzielić na wiele podzadań. Dlatego lepszym podejściem jest łączenie mniejszych zatwierdzeń dla mniejszych podzadań jednocześnie, aby uniknąć nieporęcznego rozwiązywania konfliktów.

  3. Często wycofuj swój oddział:

    Wykonuj praktykę częstego bazowania na oddziale lokalnym za pomocą oddziału zdalnego. Możesz użyć poniższego polecenia, aby często zmienić bazę na oddział lokalny na zdalny,

    git pull --rebase #or
git pull --rebase origin dev #when dev is remote branch

    To jak dotąd najbardziej przydatne polecenie git w moim życiu programistycznym.

  4. Ściśle współpracuj z członkami drużyny:

    Jeśli naprawdę potrzebujesz pracować równolegle z kolegą z zespołu w ramach wspólnego zadania, pracuj wspólnie. Może poczekać, aż uniknie skomplikowanego rozwiązania konfliktu, ponieważ jesteś początkującym i ona jest ekspertem.

  5. Bądź przyzwyczajony z opcjami git:

    Wykorzystaj moc narzędzi do łączenia git. Istnieje wiele wygodnych sposobów rozwiązywania konfliktów podczas łączenia. Strategie łączenia czasami mogą bardzo pomóc. Bądź przyzwyczajony i nieustraszony dzięki poleceniom git.

Sazzad Hissain Khan
źródło