Jak mogę zminimalizować ból git, gdy wszyscy pracują nad mistrzem?

123

Nasz zespół dokumentacyjny złożony z około dziesięciu osób niedawno przeniósł się z SVN do Git. W SVN wszyscy pracowali nad master - modelem, którego zawsze nienawidziłem, ale nie byłem w stanie wprowadzić tej zmiany. W ramach przejścia do Git zgodziliśmy się to naprawić, ale nie możemy tego jeszcze zrobić (czekamy na zmiany kompilacji, które pozwolą na kompilacje z dowolnych gałęzi). Tymczasem wszyscy pracują nad mistrzem. Tak, wiem, że to okropne, wierz mi.

Widzimy teraz znacznie więcej czkawek niż wtedy, gdy korzystaliśmy z SVN, z których niektóre są spowodowane dwustopniowym modelem Gita (lokalnym i zdalnym). Czasami ludzie popełniają, ale nie popychają, lub pociągają i napotykają konflikty z oczekującymi lokalnymi zmianami. Wczoraj ktoś zablokował ostatnie zmiany - jakoś - z nieudanym połączeniem, które, jak sądzę, było połączeniem, które Git robi, gdy ciągniesz i masz wybitne zmiany. (Nie był w stanie powiedzieć mi dokładnie, co zrobił, a ponieważ używa GUI, nie mogę po prostu sprawdzić jego historii powłoki).

Jako najbardziej biegły użytkownik Gita (czytaj: Używałem go już wcześniej, choć nie do niczego bardzo skomplikowanego), jestem osobą ustalającą zasady, uczącą narzędzi i sprzątającą bałagany. Jakie zmiany mogę wprowadzić w sposobie, w jaki używamy narzędzi, aby udostępniony, aktywny master był mniej podatny na błędy, dopóki nie przejdziemy do programowania na gałęziach?

Zespół używa Tortoise Git w systemie Windows. Używamy Tortoise Git, ponieważ wcześniej używaliśmy Tortoise SVN. ( Ja osobiście użyć wiersza polecenia pod Cygwin dla niektórych operacji, ale zespół jasno potrzebują GUI i jedziemy z tym.) Odpowiedzi powinny pracować z tym narzędziem, nie zaproponować zamienniki.

Tortoise Git ma „Commit & Push” dostępny jako pojedyncza operacja i powiedziałem im, aby zawsze to robili. Jednak nie jest atomowy - może się zdarzyć, że zatwierdzenie (które w końcu jest lokalne) działa dobrze, ale push nie działa (powiedzmy, z powodu konfliktu lub problemu z siecią). Kiedy tak się dzieje, otrzymują dwuznaczny błąd; Powiedziałem im, aby sprawdzić BitBucket popełnić dziennik jeśli mają jakiekolwiek wątpliwości ostatnie popełnić, a jeśli oni nie widzą, do pchania. (I rozwiązać konflikt, jeśli to jest problem, lub poprosić o pomoc, jeśli nie wiedzą, co zrobić.)

Zespół ma już dobry zwyczaj „ciągnąć wcześnie i często”. Wydaje się jednak, że ściąganie może powodować konflikty, które moim zdaniem są nowe? Jeśli nie nowy, znacznie częściej niż w SVN. Słyszałem, że mogę zmienić sposób, w jaki Git robi ciągnięcia (rebase zamiast scalania), ale nie mam dobrego zrozumienia dostępnych kompromisów (ani tego, jak to zrobić w naszym środowisku).

Serwer to BitBucket (nie Github). Mam pełną kontrolę administracyjną nad naszym repozytorium, ale bardziej ogólnie na serwerze. Nic z tego nie można zmienić.

Pliki źródłowe to XML. Są też pliki graficzne, o których wszyscy wiedzą, że nie można scalić, ale prawie nigdy nie mamy kolizji. Konflikty scalania pochodzą z plików XML, a nie z grafiki.

Jakie zmiany mogę wprowadzić w naszym korzystaniu z Git, aby sprawić, aby mistrz współdzielenia działał płynniej dla zespołu, dopóki nie przejdziemy do korzystania z gałęzi funkcji przy sprawdzonych, zweryfikowanych testowo żądaniach ściągania?

Monica Cellio
źródło
52
Nie używaj żółwia, używaj rozszerzeń Git. Tortoise próbuje ukryć, że Git nie jest SVN i niszczy większość wielkości gita. Dwukrotnie przeszedłem przez tranzystor SVN-> Git, a Git Extension było doskonałym narzędziem do nakłonienia ludzi do myślenia w ten sposób.
Wilbert,
91
Git nie jest SVN. Jeśli spróbujesz powielić SVN za pomocą Git, po prostu uzyskasz wszystkie punkty bólu SVN z połączonymi wszystkimi punktami bólu Git, bez żadnej z tych korzyści, to po prostu nigdy nie zadziała. Największym problemem, jaki masz, jest problem społeczny, masz członków zespołu, którzy nie chcą uczyć się nowych koncepcji. Nie możesz tego rozwiązać za pomocą rozwiązania technicznego, musisz zacząć od zdobycia wpisu od członków zespołu, aby nauczyć się koncepcji Git, zamiast próbować przekonać ich, że to jest jak SVN.
Lie Ryan,
10
Wiem, że powiedziałeś, aby nie polecać innych aplikacji, ale @Wilbert ma rację. TortoiseGit próbuje ukryć rzeczy, co w rzeczywistości czyni mnie bardziej bolesnym w moim doświadczeniu. Jeśli pożądany jest interfejs użytkownika, znalazłem najłatwiejsze przejście (czytaj: trenuję nietradycyjne zespoły oprogramowania w zakresie narzędzi i DevOps) za pośrednictwem SourceTree Atlassian (oczywiście z odpowiednim szkoleniem). Użyłem również GitFlow, aby pomóc im zrozumieć model Git (jednak nie pasuje to do wszystkich zespołów).
JasCav,
28
Jestem trochę zaskoczony, że wszyscy robią kupę kupy nad mistrzem, który jest główną zasadą ciągłej integracji . Tak długo, jak masz solidny pakiet testowy i wszyscy wiedzą, kiedy kompilacja jest zepsuta, praca od mistrza może być korzystna dla współpracy zespołu. Rozgałęzianie funkcji (na którym prawie wszystkie inne przepływy pracy polegają w pewnym stopniu) może być równie destrukcyjne bez ochrony. Prawdopodobnie masz tutaj jakieś głębsze problemy z rootowaniem.
DanK
14
@ DanK, myślę też, że operacja błędnie zidentyfikowała źródło problemu. Jeśli masz ludzi blokujących zmiany w systemie głównym i przełączysz się na oddział, będziesz mieć ludzi blokujących zmiany w gałęzi. Jeśli przeprowadzisz się do poszczególnych oddziałów, będziesz mieć osoby, które mają problemy z łączeniem się w swoich oddziałach (lub rozwijają się w swoim oddziale bez łączenia się przez wiele miesięcy).
user3067860,

Odpowiedzi:

11

Do tej pory SourceTree było najlepszym IDE do nauki pojęć, ponieważ pokazuje wszystkie odpowiednie okna dialogowe i opcje, które masz na każdym etapie, opcje domyślne są zwykle w porządku, nie zadzieraj z rebase itp. Postępuj zgodnie z normalnym przepływem:

  • Wyciągnij z mistrza, aby mieć pewność, że jesteś na bieżąco
  • Zmodyfikuj swoje pliki
  • Zatwierdź zmiany (tylko lokalnie)
  • Wyciągnij ponownie od mistrza (spowoduje to pojawienie się konfliktów)
  • Edytuj wszystkie pliki, dopóki konflikty nie zostaną rozwiązane, co oznacza, że ​​plik znajduje się w stanie propera, który chcesz zatwierdzić (brak komunikatów <<<<< HEAD i >>>> w pliku surowym)
  • Zatwierdź zmiany scalania
  • Pchać

Jeśli wszyscy postępują zgodnie z tym przepisem, powinny być w porządku.

Za każdym razem, gdy ktoś wprowadza większą lub centralną zmianę, poinformuj innych użytkowników, aby dokonali lokalnego zatwierdzenia i wyciągnęli z systemu głównego, aby nie dostawali później zbyt wielu konfliktów, a pierwsza osoba nadal jest w pobliżu, aby rozwiązać konflikty razem z nimi.

Poświęć dużo czasu, aby wszyscy zrozumieli przepływ, w przeciwnym razie mogliby obejść chwilę, a następnie poczuć się komfortowo podczas wkręcania gałęzi głównej, na przykład „użyj mojego pliku zamiast zdalnego”, aby rozwiązać konflikt, po prostu wykopać wszystkie zmiany wprowadzone przez innych ludzi.

Git jest trudnym do nauczenia się systemem, szczególnie jeśli dorastałeś ze Svn, bądź cierpliwy i daj mu czas na jego prawidłowe nauczenie się, z nowymi użytkownikami możesz czasem spędzić dzień na sprzątaniu bałaganu, co jest normalne. ;)

Mike M.
źródło
9
nitpick: SourceTree nie jest zintegrowanym środowiskiem programistycznym ...
Mathieu Guindon,
Mam teraz kogoś (innego niż mnie) testującego ten przepływ pracy (mam na myśli Tortoise Git), aby wytrząsnąć wszelkie niespodzianki / problemy. Zakładając, że nie, planuję przekazać to zespołowi za kilka dni.
Monica Cellio,
Wiem, że ta głosowana odpowiedź obejmuje wiele tych samych terytoriów, ale dopiero po tym, jak zobaczyłem przepis ułożony krok po kroku w tej odpowiedzi, naprawdę zrozumiałem, jak go zastosować, więc akceptuję ten (dla przepisu, a nie IDE :-)). Śledzimy ten proces od kilku dni bez dalszych problemów. Skoncentrujemy się również na badaniu i zrozumieniu „git way”.
Monica Cellio
100

Gdy pracujesz w tej samej gałęzi, co ktoś inny, musisz pamiętać o trzech głównych kwestiach:

  • Nigdy nie używaj, --forcechyba że naprawdę wiesz, co robisz.
  • Albo commitczy stashpraca w toku przed każdym pull.
  • Zwykle jest łatwiej, jeśli pullzaraz przed push.

Poza tym zaznaczę, że przy rozproszonej kontroli wersji nie ma znaczenia, czy twoje „oficjalne” repozytorium używa gałęzi, czy nie. Nie ma to żadnego wpływu na to, co robią poszczególni użytkownicy w lokalnych repozytoriach. Kiedyś moja firma korzystała z git do pozyskiwania lokalnych oddziałów, kiedy zupełnie inna centralna sieć VCS była używana. Jeśli tworzą lokalne oddziały dla swoich funkcji i popełniają błędy w łączeniu z lokalnymi master, to o wiele łatwiej jest to naprawić bez wchodzenia do dziennika lub innej magii.

Karl Bielefeldt
źródło
51
Zawsze pullwcześniej pushjest świetna rada, ale pójdę o krok dalej i zasugeruję, aby rozważyć, czy możesz, pull --rebasekiedy to zrobisz.
anaximander
20
@anaximander, zaleciłbym, aby wszyscy używali --rebase lub nikt ...
keuleJ
12
@TemporalWolf To też powiedzieli mi o torcie ...
BlackVegetable
15
@anaximander „wtedy nie rozwiązałeś konfliktu i robisz to źle. W tym przypadku nie można im ufać przy pomocy bazy”. Więc mówisz, że nigdy nie pomieszałeś konfliktu scalania? Musi być fajnie pracować na wystarczająco prostych podstawach kodu, aby można było dokonać takiej uogólnienia. Oto podejście Linusa do rebase, które osobiście uważam za bardziej przyjemne niż którekolwiek z tych czarno-białych podejść.
Voo
10
„Nigdy nie używaj, --forcechyba że naprawdę wiesz, co robisz”. Poszedłbym dalej Nie zezwalaj na przepisywanie historii w „głównym” repozytorium wszystkim osobom z wyjątkiem najbardziej zaufanych osób. To, czy możesz to zrobić, przynajmniej częściowo, zależy od twojego hostingu, ale BitBucket ma taką opcję.
jpmc26
68

Czy każdy może się nauczyć jednego dnia?

Od profesjonalistów korzystających z komputerów naprawdę należy oczekiwać, że nauczą się nowego narzędzia i chociaż możliwe jest popełnienie wielu błędów w dowolnym systemie VCS, powinni korzystać z tego narzędzia, ponieważ jest przeznaczone do użycia.

Najlepszym sposobem na wprowadzenie tego jest zachęcenie każdego do pracy nad własnym oddziałem, gdy dokonają zmiany (tak krótko, jak to możliwe), a następnie, gdy skończą, ponownie połączą się w master. Nie jest to zbyt daleko od obecnego sposobu pracy i wprowadza prosty przepływ pracy, do którego mogą się przyzwyczaić, dopóki nie poczują się na tyle pewni siebie, aby wykonywać bardziej skomplikowane operacje.

Nie używam okien, ale jeśli Tortoise w zasadzie ukrywa przed nimi git i udaje, że to SVN, być może Tortoise jest niewłaściwym narzędziem.

MarkJL
źródło
37
„jeśli Tortoise w zasadzie ukrywa przed nimi git i udaje, że to SVN, to może Tortoise jest niewłaściwym narzędziem”. to. Wiem, że OP powiedział, aby nie zastępować tego narzędzia, ale jeśli jest to niejasne, jak git działa w jakikolwiek sposób, szkodzi to osobistemu rozwojowi programistów i wydajności operacyjnej. Twój zespół będzie nadal niewłaściwie używał twojego VCS, jeśli go nie zrozumie.
2rs2ts
3
Innym pomocnym materiałem do nauki git jest Learn Git Branch . Pokazuje drzewo wizualne, a dodatkowo ma piaskownicę, dzięki czemu możesz wyśmiewać kilka poleceń i zobaczyć, jakie wyniki drzewa.
TemporalWolf
4
Zajęło to dużo dłużej niż jeden dzień, aby wszyscy w zespole deweloperów nauczyli się git (i nie są przygnębieni lub obłąkani), więc założyłem, że tak też będzie w przypadku zespołu doktorów. Przyjrzę się stronom wymienionym tutaj w komentarzach (może powinny być w tej lub innej odpowiedzi?).
Monica Cellio,
3
Nie nauczysz się git, dopóki nie popełnisz wszystkich błędów i nie odczujesz bólu w sprzecznych połączeniach i rebaseach, oni po prostu muszą nauczyć się krótkiego przepływu powyżej tworzenia gałęzi, zmieniając tę ​​gałąź, aby uwzględnić dowolne zmiany z master i łącząc ich gałąź z powrotem w master. Każda inna nauka, którą mogą zrobić, próbując rozwiązać ból napotkany w tym przepływie (będzie ich trochę). Przynajmniej zespół doc nie ma obaw o złamanie bazy kodu.
MarkJL
1
@ 2rs2ts Tortoise Git to wyjątkowe git gui. Instaluję go na wszystkich oknach systemu Windows i doskonale znam wiersz poleceń git. Jego połączenie jest jednym z najlepszych, jakich kiedykolwiek używałem. Wprowadziłem wielu początkujących użytkowników do korzystania z Git za pomocą Tortoise Git. Jego największym problemem jest to, że ujawnia niektóre zaawansowane opcje git za pomocą prostego pola wyboru. Tak więc opcja - force push może być wykonana po prostu zaznaczając pole w gui push. Prawdopodobnie to, co zostało zrobione, straciło pracę. Nie używam Tortoise dużo, ale jest kilka rzeczy, które naprawdę upraszczają.
gnash117
26

Czasami to, co robisz, musi się zmienić.

Największym problemem jest to, że każdy jest pracować na pana. Nie jest to typowe dla rozwoju kodu i może być również niewłaściwym modelem w twoim przypadku. Jeśli możesz to zmienić, prosząc / wymagając wprowadzenia zmian w osobnych gałęziach, będziesz w znacznie lepszej formie. Za pomocą oddziałów możesz uzyskać:

  • Wymuszaj, aby żadne wypychanie bezpośrednio nie było masterdozwolone.
  • Egzekwuj poprzez Bitbucket, że żądania ściągania są tworzone i mają przynajmniej jedną zgodę przed połączeniem . Zapewnia to, że ktoś patrzy na zmiany, a także sprawia, że ​​samo scalanie jest mniej bolesne, ponieważ interfejs użytkownika pokaże konflikty ze zdalną wersją kodu, a nie tym, co użytkownik ma na pulpicie. Zapobiega to scenariuszowi zatwierdzenia-udanego-ale-wypychania-nieudanego.
  • Wykonaj „kompilacje” na swoim repozytorium przed scaleniem. Zdaję sobie sprawę, że jest to repozytorium dokumentów, ale może sprawdzanie pisowni, skrobanie z użyciem języka legalnego, a nawet automatyczne tłumaczenie (eksportowanie elementów STRING_DEF do pliku csv) może zostać zbudowane na podstawie tej wersji. A może nie, zależy od twojej pracy.
  • Pozwól ludziom pracować jednocześnie nad wieloma różnymi rzeczami. Tak, można to zrobić również za pomocą skrytek, ale jest to nieco bardziej bałagan i coś mówi mi, że też ich nie używasz.

Jeśli nie możesz użyć rozgałęzienia, możesz rozważyć napisanie merge-and-pushskryptu, który mógłby zautomatyzować niektóre punkty bólu. Może sprawdziłby, czy użytkownik nie ma zaległości w master, wykonuje pobieranie i pobieranie, a następnie podejmuje próbę scalenia ( ewentualnie z--no-commit --no-ff ) i tak dalej.

Dan1701
źródło
3
Przejdziemy do rozgałęziania, z wszystkich wymienionych przez ciebie powodów (ale przede wszystkim kontrolowanych PR i możliwości nakazania rozwiązywania konfliktów w oddziale przed połączeniem). Czy możesz powiedzieć więcej o tym, jak zaatakować skrypt scalania i wypychania?
Monica Cellio
6
Nie zgadzam się z tą radą. Długotrwałe gałęzie funkcji mogą być znacznie bardziej niszczycielskie niż praca z poziomu głównego (co się stanie, jeśli nie będziesz mieć dobrego przepływu pracy). Martin Fowler ma świetny artykuł na ten temat. Na koniec dnia zespół PO ma problem ze współpracą z przepływem pracy, a nie z Gitem. Argumentowałbym, że więcej oddziałów po prostu zwiększy ten problem.
DanK
6
Długotrwałe gałęzie funkcji nie są tym, co zalecałem (ani nie wspominałem). Zgadzam się, że źle wpływają na „regularny” rozwój i nie byłoby tu lepiej. Regularne gałęzie „ravioli” z niewielkimi zestawami zmian, które można sprawdzić / przetestować przed połączeniem, są bardzo przydatne i nie mniej przydatne tutaj, ponieważ stanowią repozytorium dokumentacji z wszystkich powodów przedstawionych w odpowiedzi.
Dan1701,
3
Jasne, rozumiem to, co mówisz i teoretycznie nie zgadzam się z tym, ale przy obecnie omawianych tutaj problemach współpracy, nawet przy najlepszych intencjach, myślę, że oddziały zespołu OP niechcący zamieniają się w działy długo działające. Ostatecznie praca nad gałęzią linii głównej i funkcji nie jest tutaj głównym problemem. Problemem jest ogólny brak zrozumienia wlotów / wyjść rozproszonego VCS oraz brak współpracy / spójności między programistami. Rozgałęzianie funkcji samo w sobie nie naprawi tego, ale IMO zaostrzy to.
DanK
2
Zbliżamy się do konieczności przeniesienia tego na czat, ale jeśli zawsze jesteś w dziale funkcji, nie kończysz pracy. Muszą zostać połączone z wysłanym oddziałem (lub w tym przypadku opublikowane). Pozwala to na wprowadzenie automatycznych kontroli i zabezpieczeń wokół problemów napotykanych przez ich zespół. Gałąź funkcji całkowicie różni się od pracy nad masterem, ponieważ większość narzędzi (przynajmniej Bitbucket) jest skonfigurowana tak, aby zezwalać na żądania ściągania z wymaganymi zatwierdzeniami i kompilacje przed scalaniem w ramach modelu rozgałęziania, co nie dzieje się, gdy pracujemy tylko nad master.
Dan1701,
12

Podkreśl, że możesz powtórzyć scalenia

Może to być dla Ciebie oczywiste, ale byli użytkownicy SVN mogą nie być świadomi, że mogą próbować rozwiązać połączenie kilka razy. Może to zmniejszyć liczbę otrzymanych flag pomocy.

W SVN, gdy pracujesz, trunkbędziesz mieć niezamierzone zmiany siedząc. Wtedy zrobiłbyś svn update. W tym momencie twoje zmiany będą mieszać się z innymi ludźmi na zawsze. Nie było sposobu, aby to cofnąć (afaik), więc nie miałeś innego wyjścia, jak tylko ręcznie sprawdzić wszystko i mieć nadzieję, że repo było w dobrym stanie. Kiedy naprawdę wygodniej byłoby po prostu przerobić scalanie.

Ludzie mieliby taką samą mentalność, nawet gdy przeprowadziliśmy się do git. Prowadząc do wielu niezamierzonych błędów.

Na szczęście z git istnieje droga powrotna, szczególnie dlatego, że możesz dokonywać lokalnych zatwierdzeń. (Opiszę później, jak to jest wyrażone w wierszu poleceń)

Jednak sposób, w jaki to się robi, różni się w zależności od oprzyrządowania. Uważam, że powtórzenie pull nie jest czymś ujawnionym w wielu GUI jako pojedynczy przycisk, ale prawdopodobnie jest możliwe. Lubię, że używasz cygwina. Moi współpracownicy używają źródła. Ponieważ używasz BitBucket, warto używać go jako GUI, ponieważ zarządza nim ta sama firma: Atlassian. Podejrzewam, że istnieje ściślejsza integracja.

Odnośnie pociągnięć

Myślę, że masz rację, że połączenie pulljest tym, co psuje ludzi. A pulljest tak naprawdę, git fetchktóry pobiera zmiany z serwera, a następnie git merge origin/<branchname>*, który scala zmiany zdalne w oddziale lokalnym. ( https://git-scm.com/docs/git-pull )

Wynik jest taki, że wszystkie standardowe polecenia scalania działają z pull. Jeśli podczas scalania występują konflikty, możesz je przerwać git merge --abort. Co powinno zabrać cię z powrotem przed połączeniem. Następnie można spróbować ponownie albo git pullalbo git merge origin/<branchname>.

Jeśli potrafisz jakoś nauczyć się robić powyższe, korzystając z wybranego przez siebie narzędzia GUI współpracowników , myślę, że to rozwiąże większość twoich problemów. Przepraszam, nie mogę być bardziej szczegółowy.

* Rozumiem, że pochodzenie nie zawsze tak jest.

Służy git reflogdo diagnozowania problemów

Ja, podobnie jak ty, muszę zdiagnozować problemy powstałe głównie w wyniku niewłaściwego użycia narzędzi GUI. Uważam, że git reflogczasem może to być pomocne, ponieważ jest to dość spójny ciąg działań w repozytorium. Chociaż czasami trudno go czytać.

Alternatywa

Ponieważ Twoja sytuacja jest tymczasowa , możesz po prostu wrócić do SVN, dopóki nie uruchomisz procesu. Wahałbym się przed tym, ponieważ wiele miejsc mówiłoby dalej: „Próbowaliśmy raz, ale to po prostu nie działało ...” i nigdy tak naprawdę nie podniosłem go.

Niektóre inne typowe problemy przejściowe

  • Ludzie często usuwali i ponownie konfigurowali swoje repozytorium, będąc przekonani, że repozytorium jest w stanie bezużytecznym. Zwykle było to spowodowane utratą różnic lokalnych i odległych. Zarówno narzędzia GUI, jak i interfejs CLI nie pokazują tego dobrze. W CLI znajduję git log --decoratenajprostszy sposób na przegląd różnic. Ale jeśli na przykład mistrz stanie się zbyt włochaty, możeszgit reset --hard origin/master
jmathew
źródło
2
W ostatnim punkcie: dla naprawdę szybkiego, strukturalnego przeglądu, uważam za git log --oneline --decorate --graphidealny. Do tego stopnia, że ​​zdefiniowałem alias powłoki dla tej precyzyjnej kombinacji.
cmaster
1
+1 za twoją odpowiedź, po prostu uważam, że sugerowana alternatywa jest zła z powodu twojego wspomnienia. Będziesz odczuwał ból, nawet jeśli wrócisz do SVN, a następnie w przyszłości przejdziesz do git. Ludzie w zespole nauczą się nowego, innego, bolesnego narzędzia, tylko jeśli nie mają innej opcji. Dopiero po użyciu i popełnieniu głupich błędów zaczną doceniać, co potrafi git.
CodeMonkey,
8

Jednym z możliwych mechanizmów, które przyjęło wiele zespołów open source, jest użycie modelu rozwidlenia - https://www.atlassian.com/git/tutorials/comparing-workflows (pamiętaj o wyraźnym wypowiadaniu się przy omawianiu przepływu pracy z rozwidlaniem gitów ) .

W tym przypadku każdy programista lub podgrupa ma własne rozwidlenie repozytorium, które wypisuje z BitBucket, zapewnia mechanizm do tego , ustawiając źródło „w górę” oprócz domyślnego pilota - będą musieli pamiętać, aby „pobrać w górę” ”i„ regularnie łączyć zdalne / upstream / master ”.

Prawdopodobnie rozwiąże to problemy z mechanizmem kompilacji, ponieważ narzędzia kompilacji byłyby prawdopodobnie skierowane do wzorca w innym projekcie, tj. Rozwidleniu.

Następnie możesz usunąć z większości ludzi możliwość bezpośredniego przejścia do głównego projektu i uczynić z tego mniejszy zespół ludzi z rolami do przeglądu i zatwierdzania. Zobacz https://www.atlassian.com/git/tutorials/making-a-pull-request

Miejsce do przeczytania na temat zapewniania, że ​​prawie wszystkie pożądane kontrole zostaną wykonane przed wypchnięciami, znajduje się w sekcji książki git na hakach - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - możesz użyć przechwytywania wstępnego i wstępnego wypychania, aby wykonywać takie czynności, jak uruchomienie niektórych testów proponowanego zatwierdzenia, aby upewnić się, że praca jest poprawna itp. - jedynym problemem związanym z zaczepami po stronie klienta jest to, że programiści mogą je wyłączyć lub nie włączyć im.

Zarówno pobieranie / scalanie w górę, jak i przechwytywanie są dostępne w TortoiseGit.

Steve Barnes
źródło
Naprawdę niezły pomysł. Wygląda również na to, że ten zespół skorzystałby z Merge Master, dopóki nie poczują się bardziej komfortowo. +1
Greg Burghardt
2
BitBucket ma funkcję synchronizacji wideł, która automatycznie przewija widelce, gdy jest to możliwe. Bardzo wygodnie jest dziś rozwidlać i pobierać od początku w przyszłym tygodniu, nie martwiąc się o upstream.
piedar
3

To zabrzmi sprzecznie z intuicją, ale wysłuchaj mnie:

Zachęć ich, aby zaczęli eksperymentować z git

Jedną z interesujących rzeczy w git jest to, że zaskakująco łatwo jest zapewnić bezpieczeństwo każdej lokalnej operacji. Kiedy zacząłem używać git, jedną z rzeczy, które przyszło mi do głowy, było spakowanie całego katalogu jako kopii zapasowej na wypadek, gdyby coś spieprzyłem. Później odkryłem, że jest to ogromna kludge i prawie nigdy nie jest konieczna do ochrony twojej pracy, ale ma tę zaletę, że jest bardzo bezpieczna i bardzo prosta, nawet jeśli nie wiesz, co do cholery robisz i jak polecenie, które chcesz spróbować, okaże się. Jedyną rzeczą, której musisz unikać, kiedy to robisz, jest push. Jeśli niczego nie naciskasz, jest to w 100% bezpieczny sposób wypróbowania wszystkiego, co chcesz.

Strach przed próbowaniem rzeczy jest jedną z największych przeszkód w nauce gita. To daje tak wiele kontroli nad wszystkim, że jest to swego rodzaju trudne. Rzeczywistość jest taka, że ​​możesz trzymać się kilku bardzo bezpiecznych operacji przez większość codziennego użytku, ale znalezienie poleceń, które one są, zajmuje trochę czasu.

Dając im poczucie bezpieczeństwa , będą znacznie chętniej próbować wymyślić, jak to zrobić samodzielnie. Będą oni znacznie bardziej upoważnieni do znalezienia osobistego przepływu pracy na lokalnej maszynie, która będzie dla nich działać. A jeśli nie każdy robi to samo lokalnie , to jest w porządku, o ile są one zgodne z normami, co oni naciskać . Jeśli trzeba skompresować całe repozytorium przed wykonaniem operacji, aby poczuli się w ten sposób, nie ma sprawy; mogą wybierać lepsze sposoby robienia rzeczy na bieżąco i próbować różnych rzeczy. Coś, co sprawi, że zaczniesz próbować różnych rzeczy i zobaczysz, co to robi.

To nie znaczy, że trening jest bezwartościowy. Wręcz przeciwnie, szkolenie może pomóc ci zapoznać się z funkcjami, wzorami i normami. Ale to nie zastąpi siedzenia i robienia rzeczy w codziennej pracy. Ani git, ani SVN nie są rzeczami, na które możesz po prostu pójść na zajęcia i wtedy wiesz wszystko. Musisz ich użyć , aby rozwiązać problemy, aby się z nimi zapoznać i które funkcje są odpowiednie dla których problemów.

Przestań ich zniechęcać do poznawania tajników git

Wspomniałem, że nie pcham niczego, co jest sprzeczne z jedną z rzeczy, których ich uczysz: zawsze „Commit & Push”. Uważam, że powinieneś przestać im mówić, aby to zrobili i powiedzieć im, żeby zaczęli robić odwrotnie. Git ma w zasadzie 5 „miejsc”, w których można wprowadzić zmiany:

  • Na dysku, niezaangażowane
  • Zainscenizowane, ale nie zaangażowane
  • W lokalnym zatwierdzeniu
  • W lokalnej skrytce
  • Zdalne repozytoria (tylko zatwierdzenia i tagi są zawsze wypychane i przenoszone między różnymi repozytoriami)

Zamiast zachęcać ich do ciągnięcia i pchania wszystkiego w jednym kroku, zachęć ich do wykorzystania tych 5 różnych miejsc. Zachęcaj ich do:

  • Pobierz zmiany, zanim cokolwiek zatwierdzą.
  • Podejmij decyzję, jak obsłużyć pobrane zmiany. Dostępne opcje to:

    • Zatwierdź lokalne zmiany, a następnie rozłóż je na podstawie pobranych zmian.
    • Zatwierdź lokalne zmiany, a następnie scal je z pobranymi zmianami.
    • Ukryj ich zmiany, połącz, a następnie odblokuj i rozwiąż wszelkie konflikty.

      Są jeszcze inne rzeczy, ale nie będę się tutaj zajmował. Zauważ, że pull jest dosłownie tylko pobieraniem i łączeniem. To nie tak jak oni; to jest ich. (Pomijane --rebasezmiany są pobierane z fetch + merge do fetch + rebase).

  • Dokonaj zmian ich zmian, a następnie je przejrzyj.
  • Zatwierdź zmiany etapowe, a następnie przejrzyj zatwierdzenie.
  • Naciśnij osobno.

To zachęci ich do sprawdzenia swojej pracy, zanim zostanie ona publicznie udostępniona wszystkim, co oznacza, że ​​wcześniej złapią swoje błędy. Zobaczą zatwierdzenie i pomyślą: „Poczekaj, nie tego chciałem”. W przeciwieństwie do SVN, mogą wrócić i spróbować ponownie, zanim zaczną naciskać.

Po przyzwyczajeniu się do zrozumienia, gdzie są ich zmiany, mogą zacząć decydować, kiedy pomijać kroki i łączyć określone operacje (kiedy wyciągać, ponieważ już wiesz, że chcesz pobrać + scalić lub kiedy kliknąć tę opcję Zatwierdź i pchnij) .

Jest to w rzeczywistości jedna z ogromnych zalet git nad SVN, a git został zaprojektowany z myślą o tym wzorcu użytkowania. Natomiast SVN zakłada centralne repozytorium, więc nic dziwnego, jeśli narzędzia dla git nie są tak zoptymalizowane dla tego samego przepływu pracy. W SVN, jeśli twoje zatwierdzenie jest błędne, jedynym realnym wyjściem jest nowe zatwierdzenie, aby cofnąć błąd.

Takie postępowanie w naturalny sposób doprowadzi do kolejnej strategii:

Zachęć ich do korzystania z lokalnych oddziałów

Lokalne oddziały w rzeczywistości ułatwiają wiele problemów związanych z pracą na udostępnianych plikach. Mogę wprowadzić wszystkie potrzebne zmiany we własnym oddziale i nigdy nie wpłyną one na nikogo, ponieważ ich nie naciskam. Potem, gdy nadejdzie czas, mogę korzystać ze wszystkich tych samych strategii scalania i rebase'u, tylko łatwiej:

  • Mogę zmienić bazę mojego lokalnego oddziału, co sprawia, że ​​scalenie go w master jest banalne.
  • Mógłbym użyć zwykłego scalenia (utworzyć nowy zatwierdzenie) w master, aby wprowadzić w nim zmiany mojego oddziału lokalnego.
  • Mogę połączyć wszystkie moje lokalne oddziały w jedno zatwierdzenie master, jeśli uważam, że mój oddział jest zbyt wielkim bałaganem do odzyskania.

Korzystanie z lokalnych oddziałów to także dobry początek do opracowania systematycznej strategii rozgałęziania. Pomaga użytkownikom lepiej zrozumieć ich własne potrzeby rozgałęziania, dzięki czemu możesz wybrać strategię opartą na potrzebach i bieżącym poziomie zrozumienia / umiejętności zespołu, a nie tylko spadek Gitflow, ponieważ wszyscy o nim słyszeli.

Podsumowanie

W skrócie, git nie jest SVN i nie można go tak traktować. Musisz:

  • Wyeliminuj strach, zachęcając do bezpiecznych eksperymentów.
  • Pomóż im zrozumieć, czym różni się git, aby mogli zobaczyć, jak to zmienia ich normalny przepływ pracy.
  • Pomóż im zrozumieć dostępne funkcje, które pomogą im łatwiej rozwiązać problemy.

To wszystko pomoże ci stopniowo dostosować lepsze wykorzystanie git, aż osiągniesz punkt, w którym możesz zacząć wdrażać zestaw standardów.

Specyficzne funkcje

W najbliższym czasie pomocne mogą być następujące pomysły.

Rebase

Wspomniałeś o bazie zwrotnej i że tak naprawdę nie rozumiesz jej w swoim pytaniu. Oto moja rada: wypróbuj to, co właśnie opisałem. Wprowadź zmiany lokalnie, podczas gdy ktoś inny wprowadzi zmiany. Zatwierdź zmiany lokalnie . Spakuj katalog repozytorium jako kopię zapasową. Pobierz zmiany drugiej osoby. Teraz spróbuj uruchomić polecenie rebase i zobacz, co stanie się z twoimi zatwierdzeniami! Możesz czytać niekończące się posty na blogu lub szkolić się na temat rebase i tego, jak powinieneś lub nie powinieneś go używać, ale nic z tego nie zastąpi oglądania go na żywo. Więc spróbuj go.

merge.ff=only

To będzie kwestia osobistego gustu, ale polecam go przynajmniej tymczasowo, ponieważ wspomniałeś, że masz już problemy z rozwiązywaniem konfliktów. Polecam ustawienie merge.ffnaonly :

git config --global merge.ff only

„ff” oznacza „przewijanie do przodu”. Szybkie łączenie do przodu ma miejsce, gdy git nie musi łączyć zmian z różnych zatwierdzeń. Po prostu przesuwa wskaźnik gałęzi do nowego zatwierdzenia wzdłuż linii prostej na wykresie.

W praktyce uniemożliwia to gitowi automatyczne próbowanie tworzenia zatwierdzeń scalania. Więc jeśli popełniam coś lokalnie, a następnie ściągam czyjeś zmiany, zamiast próbować utworzyć zatwierdzenie scalania (i potencjalnie zmuszając użytkownika do radzenia sobie z konfliktami), scalanie po prostu się nie powiedzie. W efekcie git wykona tylko fetch. Jeśli nie masz żadnych lokalnych zatwierdzeń, scalanie przebiega normalnie.

Daje to użytkownikom możliwość sprawdzenia różnych zatwierdzeń przed próbą ich scalenia i zmusza ich do podjęcia decyzji o tym, jak najlepiej sobie z nimi poradzić. Mogę dokonać zmiany bazy, kontynuować scalanie (używając git merge --no-ffdo ominięcia konfiguracji), lub nawet po prostu odłożyć scalenie moich zmian na razie i obsłużyć je później. Myślę, że ten niewielki wzrost prędkości pomoże Twojemu zespołowi uniknąć błędnych decyzji dotyczących fuzji. Możesz pozwolić swojemu zespołowi wyłączyć tę funkcję, gdy zaczną one lepiej radzić sobie z fuzjami.

jpmc26
źródło
2

Przeszedłem dokładnie to samo doświadczenie SVN -> git w mojej firmie i z mojego doświadczenia, jedynym lekarstwem jest czas. Pozwól ludziom przyzwyczaić się do narzędzi, pozwól im popełniać błędy, pokaż im, jak je naprawić. Twoja prędkość przez jakiś czas będzie cierpieć, a ludzie stracą pracę, a wszyscy będą trochę trawersi, ale taka jest natura zmiany czegoś tak podstawowego, jak twój VCS.

To powiedziawszy, zgadzam się ze wszystkimi, którzy uważają, że TortoiseGit jest przeszkodą, a nie pomocą, na tak wczesnym etapie okresu przejściowego. TortoiseGit nie jest najlepszym GUI w najlepszym przypadku, a zaciemniając działanie git w imię prostoty, uniemożliwia również współpracownikom zrozumienie podstawowych pojęć git, takich jak zatwierdzanie dwufazowe.

Podjęliśmy (raczej drastyczną) decyzję, aby zmusić programistów do korzystania z wiersza poleceń (git bash lub posh-git ) przez tydzień, i zadziałało to cudownie dla zrozumienia, jak git faktycznie działa i czym różni się od SVN. Może to zabrzmieć drastycznie, ale proponuję wypróbować to po prostu, ponieważ pozwala to zrozumieć model git - a kiedy już go spuści, twoi współpracownicy mogą zacząć używać dowolnych fasad GUI zamiast git, który im się podoba.

Ostatnia uwaga: będą niektórzy z twoich współpracowników, którzy grokują, jak działa git prawie natychmiast, i będą tacy, którzy nigdy tego nie zrobią. W tej ostatniej grupie musisz po prostu nauczyć się mistycznych inkantacji, aby ich kod dostał się z lokalnego komputera na serwer, aby każdy mógł go zobaczyć.

Ian Kemp
źródło
1

Cóż, ostatnio dostosowałem następujący przepływ pracy, aby nigdy nie przekręcać gałęzi master:

1) Każdy korzysta z własnego oddziału, który jest pierwotnie kopią z oddziału głównego.

Nazwijmy gałąź master „master”, a moją gałąź „my_master”.

Właśnie utworzyłem swoją gałąź od mistrza, więc jest dokładnie taka sama. Zaczynam pracę nad nową funkcją w moim oddziale, a kiedy to się stanie, wykonuję następujące czynności.

W moim oddziale właśnie skończyłem kodować

git add . && git commit -m "Message" && git push

Wróć do głównej gałęzi

git checkout master

Pociągnij, jeśli nie jest aktualne

git pull

Wróć do mojego oddziału

git checkout my_master

Scal najnowszego mastera z moim własnym oddziałem

git merge master

Napraw konflikty i scalenia

Sprawdź wszystko jeszcze raz

Kiedy wszystko zostanie scalone i naprawione w moim oddziale, popchnij to

git push

Wróć do głównej gałęzi

git checkout master

Połącz się z moim oddziałem

git merge my_master

Niemożliwe są konflikty, ponieważ są one rozwiązywane we własnym oddziale z poprzednim połączeniem

Push master

git push

Jeśli wszyscy to zrobią, gałąź główna będzie czysta.

TanguyB
źródło
0

Mamy więc zespół, który przeszedł z TFS na git i zachował stare sposoby myślenia. Ogólne zasady działania są mniej więcej takie same.

Tak, oznacza to, że wszyscy pracują nad mistrzem. To nie jest takie złe; a zespół przyzwyczajony do TFS lub SVN uzna to za najbardziej naturalne.

Ogólne procedury, aby uczynić to tak bezbolesnym, jak to możliwe:

  1. rób git stash && git pull --rebase && git stash popco rano
  2. popełnić wcześnie i często (nie musimy naciskać od razu; możemy przynajmniej zacząć korzystać z git wcześnie)
  3. do wypychania wykonaj następującą pętlę:

    git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Jozuego
źródło
Jeśli to zrobisz, równie dobrze możesz pozostać przy SVN. Podobnie było w przypadku samochodów wozowych. Oczywiście możesz prowadzić samochód z taką samą prędkością, jak w przypadku powozu konnego. Ale wszystko, co osiągniesz dzięki temu, to utrudnienie sobie i doprowadzenie do szaleństwa ludzi, którzy potrafią prowadzić samochód. Naucz się prowadzić samochód. Teraz.
cmaster
@cmaster: Dla nas największą zaletą git jest to, że utrata serwera nie powoduje utraty całej historii kontroli źródła. (Stało się to do nas - musieliśmy kopie ale napęd taśm zaczęła jeść, gdy staraliśmy się przywrócić.)
Joshua
@cmaster: Od tego czasu zaczęliśmy wprowadzać inne przydatne funkcje git, ale rozgałęzienia zmian prawdopodobnie nie będą używane.
Jozuego
@cmaster Różnica między powolną jazdą samochodem a jazdą na koniu polega na tym, że jazda samochodem przygotowuje cię do szybszej jazdy. Jazda na koniu nie. Nie każdy, kto wskakuje do samochodu, musi uderzyć w gaz, aby po raz pierwszy w nim jechać z prędkością 60 mil na godzinę.
jpmc26
@ jpmc26 Kiedy brałem pierwsze lekcje jazdy, z pewnością zostałem poproszony o jazdę z prędkością 30 km / h i uważam, że ta lekcja obejmowała również krótki dystans przy prędkości 50 km / h. To zdecydowanie więcej niż typowy powóz konny. To samo dotyczy git: ogólnie uczysz się rozwidlać i łączyć od pierwszego dnia. To integralna część korzystania git. Unikaj tego, a nadużywasz narzędzia w taki sam sposób, jak nadużywasz samochodu, gdy jedziesz nie więcej niż 15 km / h.
cmaster
-3

Jeśli wszyscy pracują nad masterem, nic nie możesz zrobić. Rzeczy nieuchronnie się zepsują.

Powinieneś użyć wzorca dla kompletnych produktów wysyłanych do klienta. Należy użyć rozwój na rzecz ciągłego rozwoju i należy nie dopuszczać nikogo naciskać na rozwój. Standardem jest to, że wszyscy rozgałęziają się od deweloperów, wprowadzają zmiany, przekazują je z lokalnego do swojego oddziału na serwerze i wysyłają żądanie wypychania. Następnie ktoś przegląda zmianę i łączy ją w rozwój.

Aby uniknąć konfliktów, wszyscy przed włączeniem projektu łączą rozwój z własnym oddziałem i rozwiązują konflikty na tym etapie (więc dotyczy to tylko jednego programisty lokalnie). Jeśli połączenie z programowaniem spowodowałoby konflikty, to nie jest ono scalone - programista ponownie scala program z gałęzią i przesyła ponownie na serwer, a następnie jest ponownie sprawdzany.

Możesz na przykład użyć sourcetree, aby to działało bez żadnego bólu.

gnasher729
źródło
4
To po prostu zamienia „master” na „development”, z dodatkowym ryzykiem, że ludzie nie przestawią się na gałąź programistyczną po domyślnej realizacji transakcji. Wolę GitLab Flow , który jest szczęśliwym medium między ciężkim GitFlow a rzadkim GitHub Flow.
Cees Timmerman,
@CeesTimmerman Jeśli nie lubisz Gitflow, możesz zainteresować się także Oneflow .
jpmc26