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?

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. ;)

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.

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.

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.

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

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.

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.

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ć.

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.

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.

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.