Kontekst

Mój zespół ośmiu inżynierów przechodzi obecnie na Git (z Subversion), aby zrobić kolejną wielką rzecz. Mamy garść „bardziej doświadczonych” inżynierów, którym trudno jest zdobyć Git. Zadawano mi te same trywialne pytania pomimo dostarczenia instrukcji obsługi, szkoleń i sesji tablicy. Mieliśmy dwóch konsultantów Junior, którzy podnieśli wszystko w ciągu kilku dni i to naprawdę rzuciło światło na tę kwestię. To nie jest wzór ograniczony do Git, ale stał się widoczny.

Pytanie

Nie czuję się szczególnie przychylnie wobec inżynierów, którzy nie mogą / nie chcą się uczyć - szczególnie pracowników o takim poziomie stażu pracy, jaki mamy tutaj. Jednak chcę, aby zespół odniósł sukces i zbudował świetny produkt. Używamy scentralizowanego modelu Git Flow i wydaje mi się, że cała nowa terminologia go zaskakuje.

Czy mogę coś zrobić, aby pomóc tym pracownikom w nauce Git?

Sourcetree to klient, z którego korzysta cały zespół.

Daj im zabawkę.

Git jest trudny. Zwłaszcza jeśli kontrolujesz źródła w innym paradygmacie. Zepsułem kompilację za pierwszym razem, gdy próbowałem pracować z git. To sprawiło, że stałem się tak paranoikiem, że nie chciałem się zameldować, dopóki wszystko się nie skończy. Ukryłem wersje w folderach. Potem w końcu zorientowałem się, czego potrzebowałem, aby to ominąć:

Potrzebowałem bezpiecznego miejsca do zabawy.

Kiedy to miałem, celowo powodowałem problemy, aby móc nauczyć się je naprawiać - wszystko w moim bezpiecznym miejscu. Opracowałem wzór, którego mógłbym użyć, nawet jeśli zostałem przerwany i nadal wracam do dobrego stanu. Wkrótce ludzie przychodzili do mnie po pomoc z git. Wszystko dlatego, że poświęciłem czas na zabawę zabawką.

Jeśli po prostu rzucisz je w głęboki koniec, będziesz miał szczęście, jeśli uda im się unosić.

Przeciętny deweloper nie potrzebuje wielu gadżetów gita. Jest to rozproszony system kontroli źródła, ale większość zespołów korzysta z niego z centralnym repozytorium kanonicznym, z którego można pchać i wyciągać.

Podstawowe polecenia, których będzie potrzebował Twój zespół to:

• wyciągaj i scalaj zmiany ze zdalnego i obsługuj wynikające z nich konflikty (potencjalnie zmiana wersji)
• zatwierdzanie i wypychanie zatwierdzeń do zdalnego (lub wypychanie do tymczasowego repozytorium / gałęzi, aby zmiany zostały wciągnięte do głównego po przejrzeniu)
• Wsparcie: napraw bałagan po zrobieniu czegoś złego.

są te, których potrzebują bardziej zaawansowani użytkownicy

• obsługiwać lokalne zatwierdzenia
• zarządzać oddziałami

Dla osób niezaznajomionych z git i tych, którzy nie chcą się go nauczyć, ustaw kilka szybkich aliasowanych poleceń, aby je wykonać i upewnij się, że wszystko jest poprawne (dodaj nowe pliki, usuń usunięte pliki z repo itp.)

Upewnij się, że są one dobrze udokumentowane i wystarczająco głupie.

To jest w stylu komiksu xkcd , po prostu zapamiętaj polecenia i miej nadzieję, że rzeczy nie zostaną zbytnio pomieszane, gdy zapytają profesjonalistę.

Niech używają interfejsu użytkownika Git.

Jeśli mają doświadczenie z TortoiseSVN, TortoiseGit (tylko Windows) działa prawie dokładnie tak samo. W przeciwnym razie SourceTree (Windows + Mac) jest wspaniały - mamy wiele nie-programistycznych kontroli jakości, którzy byli w stanie łatwo opanować złożone zadania w Git dzięki SourceTree.

Ta odpowiedź próbuje odpowiedzieć na pytanie, jak zainteresować starszych programistów git, a nie na temat tego, jak gitnajszybciej się uczyć - do tego świetna książka git jest świetna lub jakakolwiek ilość samouczków (=> Google). Dobre linki z tą odpowiedzią to, że Git to czysto funkcjonalna struktura danych, a zwłaszcza krótki sposób przechowywania danych przez git .

Obawiam się, że mam raczej ponury pogląd na ten temat. Byłem dokładnie w twoich butach - jestem gitkujonem i chciałem odmienić drużynę od svn, spójrzmy prawdzie w oczy, drobne wyniki. W moim przypadku doprowadziło mnie to do aktywnej zmiany własnego postrzegania i zaakceptowania tego, że ludzie po prostu nie mogą być „zmuszeni do szczęścia”. Ludzie nie są komputerami, programowanie ich jest niezwykle trudne. Nadal cieszę się, że próbowałem, pokazało mi to w dość delikatny sposób to, co robię i czego nie chcę robić w życiu zawodowym.

Są ludzie, którzy zaczynają się motywować, gdy pojawiają się nowe rzeczy, i są tacy, którzy są zdemotywowani. Nie ma to nic wspólnego z tym git, że gitkonkretnie zawsze masz efekt „dlaczego w ogóle powinniśmy go używać, jeśli svnjest w porządku?”, Co stanowi ogromną barierę psychologiczną.

Ponadto naprawdę grokking gitwymaga intensywnego zainteresowania abstrakcyjnymi strukturami danych. Może to zabrzmieć niewiarygodnie, ale z mojego doświadczenia wynika, że ​​są programiści, którzy w ogóle nie są zainteresowani, i którzy są znudzeni i przeciążeni elementami bardziej złożonymi niż proste tablice. Możesz spierać się w kółko, czy ci powinni wykonywać pracę, którą wykonują, ale tak właśnie jest.

Jeśli ludzie nie są zainteresowani, nie zrozumieją. Prosty i prosty. Założę się, że brak zainteresowania jest główną przyczyną złych ocen w szkole, a nie braku inteligencji.

To powiedziawszy, byłby to program nauczania, gdybym go zastosował, oparty na gromadzeniu wiedzy od dołu do góry. Dla mnie to nie zadziałało, ale możesz wziąć to za inspirację, aby rzucić własne.

GUI

Natomiast następujące podejście niekoniecznie musi GUI poparcie dla działań ( git addw świecie repozytorium Hello ...), to pomaga ogromnie mieć GUI do wizualizacji repozytorium, od samego początku. Jeśli nie możesz zdecydować, którego użyć, wybierz gitkostateczność. Jeśli twoi faceci używają dowolnego edytora wizualnego, znajdź ich gitkomponent GUI.

Kluczowa jest (statyczna) struktura danych

Zacznij od wyjaśnienia wewnętrznych typów danych (są tylko trzy plus jeden: obiekty BLOB, drzewa, zatwierdzenia, tagi z adnotacjami, z których ostatni nie ma żadnego znaczenia na tym etapie) i ich struktury. Możesz to łatwo zrobić na tablicy / ołówkiem; drzewo jest łatwe do narysowania, ponieważ nigdy nie można go zmienić, możesz dosłownie dodawać rzeczy przez cały czas. Można zrobić sesję zabaw w świeżo utworzonym lokalnym repozytorium i użyć git cat-filedo zbadania rzeczywistych obiektów, aby pokazać im, że są one w rzeczywistości tak trywialne jak reklamowane.

Jeśli możesz im pomóc to zrozumieć

• ... w historii są dosłownie tylko 3 typy obiektów, wszystkie bardzo proste, prawie trywialne i
• ... większość gitpodkomend po prostu „masuje” te obiekty w taki czy inny sposób, wykonując niemal trywialne operacje (w zasadzie jest tylko jeden: dodaj gdzieś nowe zatwierdzenie) i ...
• ... wszystko można łatwo zobaczyć przed sobą lsi git cat-file...

wtedy będą mieli mentalne tłumaczenie tego, co faktycznie znajduje się w repozytorium. W tym momencie seniorzy mogą pamiętać, że wnętrze to magia tajemna svn(kiedykolwiek miałeś problemy z zamkami w repozytorium svn lub z „reintegrującymi” gałęziami i tak dalej?), A to może tylko trochę je motywować.

Jednym z problemów, szczególnie wśród ludzi, którzy są przyzwyczajeni svn, jest przyzwyczajenie się do tego, że jedno zatwierdzenie (obiekt, a nie akcja) zawsze jest całym drzewem katalogów. W svnludzie są używane do zatwierdzania pojedynczych plików. Jest to całkowicie odmienne podejście. Aha, i fakt, że ten sam termin „zatwierdzenie” jest używany zarówno dla obiektu statycznego, jak i akcji, również nie pomaga.

Innym problemem dla svnfacetów jest to, że svnużywa historii liniowej, a nie drzewa. To znowu jest zupełnie inne. Czas więc bardzo dużo wskazać na te różnice .

Działania wyjaśnione w odniesieniu do struktury

Kiedy zrozumieją, z jakich części gitskłada się repozytorium, nadszedł czas, aby pokazać im dokładnie, co gitrobią poszczególne podkomendy.

Mówię o add, commitw połączeniu z lokalnym katalogiem roboczym i sceną (upewnij się, że rozumieją, że katalog roboczy nie jest taki sam jak obszar pomostowy, który nie jest taki sam jak repozytorium).

Kiedy zrozumieją, że te polecenia po prostu powiększają drzewo (które, na tym etapie, składa się z 3 rodzajów - obiektów blob, drzew, zatwierdzeń, a nie tylko zatwierdzeń), możesz zrobić pierwsze git pushi git pull(w trybie szybkiego przewijania do przodu! ), aby pokazać im, że gitdosłownie przesuwa tylko swoje obiekty, że skróty to tak naprawdę tylko skróty zawartości, że możesz łatwo kopiować te elementy za pomocą polecenia kopiowania systemu plików i tak dalej.

Oczywiście, trzymaj się z dala od wszelkich nieistotnych opcji tych poleceń, mówimy git add hello.txttutaj.

Gałęzie

Pamiętaj, że rozgałęzienie jest szczególnie trudne dla svnludzi, ponieważ jest zupełnie inne. svnModel jest znacznie łatwiej wyobrazić, jak tam jest w zasadzie nic do wizualizacji - jest na widoku. gitModel nie tak dużo. Upewnij się, że od samego początku są świadomi, że gałęzie i znaczniki są po prostu „karteczkami”, które gdzieś wskazują, i że tak naprawdę nie „istnieją” w kontekście statycznej, niezmiennej historii.

Następnie wykonaj przykład po prostym przykładzie, aby pokazać, co możesz z nimi zrobić. Ponieważ wydaje się git, że jesteś przyzwyczajony , nie powinieneś mieć problemów ze znalezieniem motywacji. Upewnij się, że zawsze widzą to w kategoriach wzrostu drzewa.

Jeśli tak, możesz wyjaśnić, jak git pullto jest naprawdę git fetch && git merge; jak wszystkie repozytoria faktycznie zawierają dokładnie te same obiekty ( git fetchjest prawie tak samo jak kopiowanie rzeczy w scpkatalogu obiektów git) i tak dalej.

Prawdopodobnie, jeśli do tego czasu nie dotrzesz, aby obudzić ich zainteresowanie, możesz równie dobrze się poddać, ale jeśli uda im się dotrzeć tak daleko, to będą mieli do dyspozycji wszystkie narzędzia mentalne i nie powinno ich być niewiele w grę wchodzi już strach. Reszta (git workflow ...) powinna być wtedy z górki.

Ostatnie słowa

To brzmi jak duży wysiłek i naprawdę tak jest. Nie sprzedawaj tego jako „potrzebujemy tego do tego projektu”, ale „to pomaga ci osobiście się rozwijać i pomoże ci we wszystkich twoich dalszych interakcjach”. Potrzebujesz na to dużo czasu, a czas to pieniądz. Jeśli nie masz akceptacji kierownictwa, może to po prostu nie być tego warte; powinieneś porozmawiać o tym ze swoim szefem.

Jeśli zdecydujesz, że chcesz zrezygnować z nauczania programistów, którzy najwyraźniej nie są w stanie go zrozumieć, ale absolutnie musisz go użyć gitw przyszłości, zastanów się nad zastąpieniem wszelkiej interakcji gitpoleceniami za pomocą gotowych skryptów lub jakiegoś GUI, który zabiera wszystkie gitszczegóły. Wlej całą kontrolę błędów itp. Do skryptów i spróbuj ją uruchomić.

Chciałbym odesłać cię do tego wpisu na blogu autorstwa Joela Spolsky'ego .

Powód, dla którego widzisz, że młodsi programiści szybko go podnoszą, jest bardzo prawdopodobny, ponieważ nie mają oni z góry ustalonego pojęcia, jak ogólnie działa kontrola wersji, a przynajmniej nie jest tak głęboko zakorzenionym modelem mentalnym. Jako takie wchodzą z czystym kontem. Twoi bardziej zaawansowani programiści prawdopodobnie próbują zastosować koncepcje, które już znają, i z tego powodu zawodzą.

Poza tym, o ile nie lubię tego mówić; kto faktycznie czyta instrukcje obsługi? Zazwyczaj bardzo źle tłumaczą podstawowe użycie. Wystarczy spojrzeć na stronę git commit z podręcznika i zastanowić się, ile nowych terminów i zwrotów wprowadza ktoś, kto nie jest na czasie z tą koncepcją. Bez dobrego wstępu prawdopodobnie zrezygnowałbym z używania Git od razu.

Moją osobistą radą byłoby zacząć wyjaśniać polecenia:

• git add <pliki>
• git commit
• git pull
• git push
• status git

Logiczne scalanie konfliktów należy wyjaśnić dalej, ponieważ to na pewno będzie twój pierwszy problem, gdy ludzie nauczą się, jak popełniać kod.

Zazwyczaj pojawiają się sytuacje, w których ludzie będą musieli poświęcić więcej czasu na naukę (przywracanie, tagi, łączenie konfliktów, gałęzi, bazowanie, przechwytywanie), ale próba wyjaśnienia tego wszystkiego, zanim będzie to potrzebne, nie pomoże ludziom, którzy mają problemy z dostaniem się do przepływ.

Podsumowując: z mojego osobistego doświadczenia, niektórzy ludzie po prostu nie spędzają dużo czasu na badaniu nowych technik, koncepcji lub narzędzi i zwykle wybierają rzeczy, które wprowadzasz w wolniejszym tempie. Nie oznacza to, że są złymi programistami lub złymi ludźmi, ale zazwyczaj mają węższy zestaw umiejętności.

Git jest poważnym przemyśleniem, jeśli nauczyłeś się kontrolować źródła w SVN. Wiele nawyków, które tam rozwinąłeś (które mogą być najlepszą praktyką dla SVN) wprowadzi cię w błąd podczas korzystania z git. Wynika to przede wszystkim z tego, że model rozgałęziania git jest tak zasadniczo odmienny. Nie wykorzystuje folderów dla gałęzi, a także można uczynić go nieliniowym, ponieważ został zaprojektowany w celu lepszej obsługi rozproszonych przypadków użycia. Odnalezienie nawyków SVN i zrozumienie, w jaki sposób powinieneś używać git, zajmuje trochę czasu .

Zacznij prosto

Mówisz, że wybrałeś Gitflow jako standard zarządzania oddziałami. To wydaje mi się twoim największym błędem.

Cytując Gitflow uważane za szkodliwe :

Wszystkie te gałęzie, które są używane, zmuszają GitFlow do posiadania skomplikowanego zestawu skomplikowanych reguł opisujących ich interakcje. Reguły te, w połączeniu z niematerialną historią, sprawiają, że codzienne korzystanie z GitFlow jest bardzo trudne dla programistów.

Czy potrafisz zgadnąć, co się stanie, ilekroć utworzysz złożoną sieć takich reguł? Zgadza się - ludzie popełniają błędy i łamią je przypadkowo. W przypadku GitFlow dzieje się tak przez cały czas. Oto krótka, bynajmniej nie wyczerpująca lista najczęstszych błędów, jakie zaobserwowałem. Są one powtarzane stale, czasem codziennie, często w kółko przez tych samych programistów - którzy w większości przypadków są bardzo kompetentni w innych obszarach oprogramowania.

Twoi programiści są prawdopodobnie przytłoczeni samą złożonością tego standardu. Osobiście nie sądzę, aby miało to jakąkolwiek korzyść, a powyższy artykuł przedstawia ten sam argument. Ale to osobna dyskusja. Obiektywnie jest to jednak dość ciężki standard z dużą ilością ręcznego zarządzania i wymaga dużego wysiłku poznawczego.

Musisz zacząć prostsze. Nie przejmuj się teraz standardem rozgałęziającym. Skoncentruj się na przyzwyczajeniu się do korzystania z gita w pierwszej kolejności. Aby rozpocząć, naprawdę potrzebujesz tylko kilku operacji:

• klon
• przyciąganie, ciąg
• gałąź
• łączyć
• popełnić
• Pchać
• wiedza o tym, jak .gitignoredziała
• może tag

Tak, twoja historia może początkowo wyglądać na trochę niechlujną. To jest w porządku. Nie martw się teraz. Zdobądź je za pomocą git .

Stopniowo zwiększaj wiedzę

Odtąd możesz stopniowo uczyć ich nieco bardziej zaawansowanych zastosowań.

• Naucz ich epickiego polecenia skrytki
• Naucz ich, jak korzystać z resetowania, gdy chcą wyrzucić lokalne zatwierdzenie, które właśnie wykonali
• Naucz je poprawiać
• Naucz ich, jak dokonać zmiany bazy, aby uniknąć niepotrzebnych zatwierdzeń scalania
• Naucz ich, jak interaktywnie bazować, aby organizować swoje zobowiązania, zanim zaczną działać
• Naucz ich, jak mogą realizować transakcje z dowolnego skrótu, znacznika lub gałęzi

Szczególnie upewnij się, że korzystasz z okazji, aby pokazać im czystsze sposoby wprowadzania ich kodu do repozytorium, ale także ucz tego tego podczas działań szkoleniowych i tego, co masz. Posiadanie jednego lub dwóch guru, do których ludzie mogą się zbliżyć, gdy nie są pewni, co robić, również bardzo pomoże. Jeśli masz coś takiego jak Slack, stwórz dedykowany kanał i zachęcaj ludzi do zadawania pytań i odpowiadania na nie.

Następnie wybierz standard rozgałęzienia

Kiedy już większość spółki właściwy w użyciu git w ogóle, wtedy można spojrzeć na standardy rozgałęzienia. Wybór jednego z przodu jest naprawdę złym pomysłem z wielu powodów:

• Nie mają wystarczającej wiedzy o narzędziu, aby stwierdzić, czy standard działa dobrze w przypadku zastosowań firmy
• Nie będą w stanie zaoferować alternatywnych standardów
• Muszą nauczyć się zarówno narzędzia, jak i standardu w tym samym czasie
• Niektórzy przyjmą, że wybrany przez ciebie standard jest jedynym sposobem, w jaki mogą używać git
• Nie będą w stanie zidentyfikować rzadkich przypadków, w których standard wyrządza więcej szkody niż pożytku

Nie powinieneś przekazywać przepływu pracy Git z góry. Twój zespół musi mieć w tym swój wkład i być w stanie wyrazić opinię na temat tego, czy idzie dobrze, czy nie. Nie mogą tego zrobić, jeśli jeszcze nie rozumieją podstaw. Nie potrzebujesz każdego programisty, aby mieć tak głęboką wiedzę, ale zdecydowanie potrzebujesz kilku, którzy naprawdę ją zdobywają. I potrzebujesz ogromnej większości, by mieć przynajmniej kompetencje w git, aby wiedzieli wystarczająco dużo, aby pozostać nieco na szynach.

Oto kilka alternatyw dla Gitflow, które zespół może rozważyć:

• OneFlow
• Przepływ pracy gałęzi funkcji
• Scentralizowany przepływ pracy

Spójrz na nich i Gitflow, porównaj je z przypadkami użycia i wybierz taki, który pasuje.

Uważam, że przepełnienie stosu jest bardzo pomocne, kiedy po raz pierwszy podjąłem terminologię Git. Pytania takie jak te były dla mnie bardzo przydatne (głównie ze względu na ich zwięzłość) i przez pierwsze kilka tygodni korzystałem z nich w zakładkach. Może wydrukujesz kilka pogrubionych odpowiedzi? Zwłaszcza schemat na pierwszym.

Jakie są różnice między „git commit” a „git push”?

Jaka jest różnica między „git pull” a „git fetch”?

Odkryłem również, że wizualna reprezentacja pnia jest niezwykle przydatna, ale już pokrywasz ją za pomocą SourceTree.

_{Poza tym ten fragment prawdopodobnie należy do komentarza, ale brakuje mi przedstawiciela: jestem jednym z młodszych konsultantów wymienionych w pytaniu. Zanim zacząłem, miałem pojęcie, czym jest system kontroli źródła i nacisnąłem SVN dosłownie dwa razy, Gusdor daje mi więcej uznania, niż zasłużyłem. Cały zespół miał wysokiej jakości specjalistyczne szkolenie Git, zabawki i czas na zabawę. Problem nie dotyczy instrukcji Gusdora. Mam nadzieję, że istnieje dobre alternatywne rozwiązanie tego problemu, żebym mógł utworzyć zakładkę i dowiedzieć się więcej.}

Kup im książkę

Szczerze mówiąc, zakochałem się w opisanym przez ciebie obozie. Pochodzę z tła SourceSafe i ClearCase. Początkowo Git był dla mnie całkowicie nieprzenikniony, mimo że mój szef kilka razy przez niego przechodził.

Pomogła mi książka, która jasno opisywała, co się dzieje, ale co ważniejsze, Git był zasadniczo inny niż jakikolwiek inny system kontroli źródła, z którego korzystałem wcześniej. Teraz wolę Git niż jakikolwiek inny wybór.

Niestety, nie mogę sobie przypomnieć, którą książkę czytałem w tym czasie, ale upewnij się, że któraś dla nich (lub wskazując na nią) skupia się na tym, jak jest różna i jak wymaga innego sposobu myślenia.

Najlepsze przypuszczenie dotyczące rekomendacji książki to:

Pro Git autorstwa Scott Chacon (link Amazon dla łatwości ... kup od kogo chcesz: https://www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6 )

Uwaga : nie kupuj książki referencyjnej dla Git. To wcale nie pomoże.

Z mojego doświadczenia wynika, że ​​niektórzy ludzie mogą swobodnie korzystać z git, nie rozumiejąc go. Znajdują podstawowy samouczek, wybierają podstawowe polecenia i są gotowi do pracy. Prawdopodobnie właśnie tam pasują do ciebie młodsi konsultanci. Nie wierzę, że naprawdę możesz nauczyć się gita w kilka dni!

Inni ludzie nie mogą tego zrobić, muszą zrozumieć, co robi git, a to zajmuje więcej czasu. Byłem w tej kategorii; Uważam, że bardzo pomocne jest granie z zawartością .gitkatalogu, wtedy zaczęło się dla mnie klikanie. Pomogły również sesje jeden na jednego z naszym liderem technologicznym.

Możesz wykonywać samouczki jeden na jeden, ponieważ ludzie uczą się inaczej i mogą być bardzo zdezorientowani co do różnych części, w sesji jeden na jednego łatwiej jest zobaczyć i rozwiązać. Jeśli naprawdę przeszkadza im to, że nie rozumieją, jak git śledzi gałęzie, pokaż im zawartość .gitkatalogu i tak dalej ...

Zabawiam się przedstawieniem, gitgdzie jestem (z TFS), więc twoje pytanie jest dla mnie na czas, zwłaszcza, że ​​miałem trochę odpychania, gdy poruszałem ten temat.

W Peopleware podstawowe tezy całej książki to:

Głównymi problemami naszej pracy są nie tyle technologiczny jako socjologiczny charakter .

Mówię o tym, ponieważ nasz nie stanowi problemu technicznego. git, choć trochę tępy, prawdopodobnie nie wykracza poza twoje lub moich starszych deweloperów, chyba że są wyjątkowo głupi *.

Spójrzmy na to z punktu widzenia twórców, jako ludzi, a nie maszyn technicznych:

Prosisz ich, aby przestali używać systemu kontroli źródła, którego (prawdopodobnie) opanowali, do takiego, którego nie mają. To trochę tak, jakby poprosić giteksperta o zaprzestanie używania giti przejście do svnniego, prawda? Sądzę, że ekspert od gitów byłby zirytowany i prawdopodobnie nie włożyłby wiele wysiłku, svnponieważ gitdziała dobrze, a są takie części, które naprawdę jej się podobają, a które naprawdę trudno zrobić svn.

Prawdopodobnie dlatego juniorzy lepiej sobie z tym poradzili - być może nie znają się na rzeczy svni gitmają szansę to rzucić ^.

Seniorzy są jednak ostrożni z kosztami alternatywnymi - jeśli się nauczą git, to nie będą:

• Uczenie się React / Angular / Swift / Blockchain / Kotlin (coś, co według nich powinno się uczyć).
• Robienie majsterkowania / marszczenie / żeglarstwo / poezja / glockenspiel / cokolwiek innego, co naprawdę chcą robić.
• Spędzanie czasu z dziećmi / krewnymi / przyjaciółmi / znaczącymi innymi osobami.

• Realizacja tej „wielkiej nowej rzeczy” - jest termin, budżet itp. Prawdopodobnie się o to martwią.

  „Muszę wykonać wszystkie powyższe czynności, dlaczego muszę z nich korzystać, git gdy mamy już kontrolę źródła?”

Jakie powody podaliście im, aby przeszli z jednej rzeczy, w której są dobrzy, na inną, która jest szczerze mówiąc niezręczna, gdy jesteście w tym nowi, i wymaga całkowitego przemyślenia tego, jak się rozwija? Czy wyjaśniłeś zalety gitfunkcji?

Żądania ściągania? Drobiazgowe meldowanie? Rozproszone źródło? Widelce?

Czy wprowadzili te powody? Są to ogromne zmiany strukturalne, jeśli jesteś w scentralizowanym systemie kontroli źródła - nie tylko zmiany techniczne, ale także kulturowe, a wiemy, jak trudno jest zmienić kulturę.

Zasadniczo zastanów się, o co prosisz programistów, i upewnij się, że dzieje się tak z właściwych powodów. Jeśli chcesz to zrobić, bo svnjest głupie i stare, a nikt już nie używa, to dobrze, ale trudniej jest sprzedać innym, którzy nie myślą tak jak Ty i po prostu chcą zacząć dzień. Musisz podać korzyści w sposób, który ma sens dla Twojego zespołu i projektu. Jeśli uda Ci się skłonić ich do gitzgodzenia się, że jest to warte bólu, nie musisz się martwić, że nauczą się technologii, po prostu zgadzając się na skonfigurowany przez Ciebie przepływ pracy.

Powodzenia.

Myślę, że jest to mniej pytanie inżynierskie, a bardziej psychologiczne. Chciałbym odnieść się do Algorithms to Live By: The Computer Science of Humand Decisions. W nim autor porusza temat kompromisu eksploracja / wykorzystanie. Ludzie zwykle przechodzą fazę eksploracji, a następnie fazę wykorzystywania (wykorzystywania) tego, co odkryli. Za tym stoi pewna solidna teoria matematyczna, aby uzyskać optymalne wykorzystanie czegoś w określonym przedziale czasowym.

Dotyczy to również wieku i doświadczenia. Ludzie postrzegają swoje życie jako przerwę, a po pewnej fazie eksploracji optymalne jest rozpoczęcie korzystania z twojej wiedzy. Zacytowali badanie, w którym zapytano starszych uczestników, czy chcą spotkać kogoś sławnego, kogo lubią, czy raczej członka rodziny. Zazwyczaj wybierali członka rodziny, podczas gdy młodsi ludzie częściej wybierali sławną osobę. Jednak poproszeni o wyobrażenie sobie, jak zdecydowaliby, że będą 20 lat młodsi, osoby starsze rutynowo wybrały także sławną osobę. Co sugeruje, że ludzie przestają budować swoje sieci społecznościowe, gdy uważają, że mają mniej na eksploracji niż na wykorzystywaniu tego, co już wiedzą.

Twoi starsi inżynierowie są prawdopodobnie starsi, prawdopodobnie przeszli przez kilka systemów kontroli wersji. SVNjest prawdopodobnie najlepszym, jakiego używali do tej pory (przynajmniej patrząc na starsze systemy wersjonowania, z których korzystałem, SVN pokonał je wszystkie).

Ich optymalną strategią jest wykorzystanie SVN, ponieważ dokonali eksploracji i odkryli, że jest to najlepsze, co wykorzystują teraz.

To podstawowa psychologia człowieka i setki tysięcy lat ewolucyjnej optymalizacji, z którą walczysz.

Musisz im pokazać a) jak długo mają przed sobą karierę, aby przygotować ich do myślenia z innej perspektywy na temat przedziału, w którym się widzą oraz b) zapytać ich, co według nich jest świetne, a co „ zaginął w SVN. Możesz przedstawić setki korzyści git, ale będą już mieli jasne pojęcie, dlaczego SVNjest najlepszy, w końcu doświadczyli prawdopodobnie 5 systemów kontroli wersji. Musisz znaleźć szczelinę w zbroi tego argumentu, a następnie sprawdzić, czy gitmożna rozwiązać te problemy, wtedy przekonają się.

Nie dawaj im narzędzia ani GUI do korzystania z Git. To tylko myli rzeczy. Git został zaprojektowany do działania w linii poleceń, więc prawdopodobnie powinno być to miejsce, w którym się go uczy. Każdy GUI może mieć własne warunki i osobliwości, trzymaj się tego, co proste.

Następnie przyjrzyjmy się niektórym problemom, które Git robi lepiej niż SVN. Aby twój zespół się tego nauczył, musisz zmotywować ich do przekonania się, dlaczego git jest lepszy.

• Możliwość zatwierdzenia bez połączenia z siecią
• Możliwość tworzenia i zabawy z własnymi gałęziami
• Łaty, które można przesyłać między sobą i nadal scalają ścieżkę
• zbieranie wiśni bez bólu.
• zmiany zasad
• znajdowanie błędów za pomocą splotu git

Jestem pewien, że SVN zmieniło się w ciągu ostatnich kilku lat, ale kiedyś były to rzeczy, które powodowałyby ból. Jeśli deweloperzy zauważą, że to nowe narzędzie nie jest tylko wymyślną rzeczą, ale ma solidne zalety w swojej pracy, może być bardziej prawdopodobne, że się za nim zgodzą.

Jest to nowa rzecz do nauczenia się i istnieje wystarczająco dużo podobieństw, które mogą być mylące, ale tak naprawdę w 2017 roku DCVS jest praktycznie niezbędną umiejętnością dla każdego twórcy.

Powiedz im, żeby się nie martwili

W Git po podjęciu pracy jest prawie niemożliwe do stracenia. Jedyną pracą, którą możesz łatwo stracić, jest praca, która nie została jeszcze popełniona.

Pokaż im, jak git reflogdziała. Nie muszą wiedzieć, jak go używać; muszą tylko wiedzieć, że tam jest, aby uzyskać pomoc w odzyskaniu pracy, jeśli coś pójdzie nie tak.

Następnie nałóż na nich tę jedną prostą zasadę: w razie wątpliwości dokonaj. Zawsze mogą wycofać zatwierdzenie później (nawet z pilota!).

Nie używaj GUI

GUI da im szybszy start, ale tak naprawdę nigdy nie zrozumieją Gita. Ponadto odkryłem, że to nie „prawie niemożliwe do stracenia” zaangażowanej pracy podczas korzystania z Git GUI. Widziałem GUI, które robią okropne rzeczy, takie jak prezentowanie listy kontrolnej podczas scalania, a następnie, jeśli użytkownik odznaczy element, usuń ten plik z historii bez ostrzeżenia i zapisu. GUI jest znacznie gorszy niż zwykłe uczenie się Git z wiersza poleceń.

Zatwierdzanie kodu parowania programu

Nauka, git add -Apo której następuje, git commitnie powinna być zbyt trudna, ale szczególnie podczas łączenia (lub zmiany) z pilotem będą potrzebować pomocy. Wyjaśnij, że każdy może poprosić o pomoc w dowolnym momencie. Czekaj, pisząc polecenia i robiąc notatki. Z czasem stopniowo zwiększają liczbę sytuacji, z którymi mogą sobie poradzić bez pomocy.

Git jest już bezpieczny

Ktoś powyżej mówił o „bezpiecznym miejscu do zabawy”. Ale Git to bezpieczne miejsce. Są tylko dwa normalne, codzienne przypadki, w których łatwo stracić pracę:

• Niezatwierdzony kod
• Korzystanie z GUI

Upewnij się, że dokonują wcześnie i często i że nie zaczynają złą ścieżką z GUI, a wkrótce zobaczą, że mogą zaufać Gitowi ze swoim kodem jeszcze bardziej niż w innych systemach kontroli źródła w przeszłości.

Radziłbym spojrzeć na Gitless . Jest to wrapper nad gitem, który znacznie upraszcza podstawowy przepływ pracy (nie musisz martwić się o obszar przejściowy, gałęzie przechowują własne kopie robocze plików, prostsze zastosowania git rebasesą obsługiwane za pomocą gl fuseitp.), Zachowując jednocześnie podstawowe repozytorium git do współpracy lub jeśli musisz zrobić coś niezwykłego. Ponadto wiadomości są nieco bardziej przyjazne dla początkujących. A polecenia są wystarczająco blisko, aby git działał jako odskocznia, jeśli z jakiegokolwiek powodu muszą używać systemu bez gitów.

Próbowałem udokumentować podstawy korzystania z wiersza polecenia git. To wciąż było mylące - zarówno dla mnie (który miał doświadczenie w korzystaniu z Perforce i Source Safe), jak i dla programistów, którzy woleli stary paradygmat „zapakuj odpowiednie foldery”. Niepokojące było to, że nieprzezroczyste narzędzie modyfikowało zawartość mojego katalogu roboczego i często musiałem kłócić się z tym narzędziem, aby wprowadzić określone zmiany do mojego katalogu roboczego.

Zamiast tego używam dwóch rodzajów pośrednich.

• Korzystam z GitKraken, aby zapewnić wizualną historię moich gałęzi oraz GUI, które ukrywa instrukcje wiersza poleceń. GitKraken obsługuje interakcje między zdalnym repozytorium „origin” a moim zdaniem gitem jest mój lokalny katalog roboczy.

• Trzymam również „prawdziwy” lokalny katalog roboczy, który jest niezależny od tego, co git uważa za mój lokalny katalog roboczy. Ręcznie synchronizuję te dwa działające katalogi, co pozwala mi czuć się o wiele bardziej komfortowo, niż że wszelkie zmiany w moim katalogu roboczym są tym, co zamierzałem mieć.

Czy mogę coś zrobić, aby pomóc tym pracownikom w nauce Git?

Czy na pewno chodzi o Git, a nie o coś innego? To, co otrzymałem z komentarza, to to, że kierownictwo postanowiło coś zmienić bez uzyskiwania wpisu od starszych współpracowników i zleca im kogoś młodszego, aby poprowadził zmianę. To wydaje się dobrym punktem wyjścia do niepowodzenia, bez względu na zmianę. Złożoność gitów nie jest problemem, problem polega na tym, że zmiana, której nie potrzebują, jest na nich wymuszana.

Więc nie skupiaj się na tym, jak nauczyć ich Git, dopóki nie zauważą korzyści dla przełącznika, będą ciągnąć swoje stopy. Pokaż im, w jaki sposób Git jest rozwiązaniem problemów, które mają teraz. Nie w jaki sposób Git może zapewnić im rzeczy, których jeszcze nie potrzebują, nie w jaki sposób Git zapewnia rozwiązanie problemów innych ludzi, w jaki sposób Git rozwiązuje problemy, z którymi teraz walczą. Zatem nauczenie ich Git nie będzie problemem.

Często Git jest wykorzystywany w firmie do rozwiązywania problemów z oddziałami. Tak, lepiej jest w gałęziach niż Subversion, ale nie robi żadnej magii.

Jest bardzo prawdopodobne, że doświadczeni programiści pracują w wielu firmach, które mają.

• Utworzono oddziały, ponieważ kierownictwo nie chce decydować między sprzecznymi wymaganiami
• Użyłem gałęzi dla każdego klienta zamiast przełączników konfiguracji.
• Musiałem mieć oddział naprawiania błędów dla każdego klienta, ponieważ kierownictwo nie było skłonne zmusić wszystkich klientów do uaktualnienia do tej samej wersji oprogramowania
• Itp.

Dlatego gdy tylko niektórzy powiedzą mi, że narzędzie jest dobre w rozgałęzianiu, mój umysł mówi mi.

Kierownictwo nie chce decydować o tym, w jaki sposób zmierza firma, i wolałbym, aby zmarnowałem życie, łącząc moją pracę w 101 różnych branżach, wraz z testowaniem 101 różnych wersji oprogramowania.

Również koncepcja, że ​​dwie osoby będą jednocześnie pracować nad tym samym plikiem, jest „dobra”, jest po prostu nie do przyjęcia dla kogoś, kto doświadczył dobrze zarządzanego projektu, dlatego promowanie Git jako narzędzia do tego nie jest prawdopodobne. programiści cię lubią.

Za każdym razem, gdy patrzę na historię w Git, bardzo trudno jest zrozumieć, dlaczego zmieniano kod, ponieważ 50% lub więcej historii to scalenia, które logicznie nigdy nie powinny być publiczne i stają się bez znaczenia, gdy tylko kod opuszcza programistów maszyna.

Ale chciałbym pracować gdzieś:

• Żaden kod nie dostaje się do systemu centralnego, dopóki nie zostanie skompilowany i przetestowany jednostkowo na serwerze zaufania.
• Istnieje prosty sposób na śledzenie recenzji kodu
• Gdziekolwiek robię „get”, kod zawsze się kompiluje i działa
• Gdzie mogę wcisnąć moje zmiany bez konieczności ścigania się z kimś innym lub bez konieczności błąkania się w biurze, aby sprawdzić, czy zepsułem wersję.

Więc rozwiąż prawdziwe problemy, a jeśli Git jest częścią rozwiązań, które kupią doświadczeni programiści, ale nie oczekuj, że polubią Git tylko dlatego, że jest fajną zabawką, która może „magicznie łączyć”.

Dlatego wszędzie tam, gdzie programista przesuwa się z lokalnego Gita do centralnego Gita, robi to źle, kontrolowany zautomatyzowany proces powinien brać zmiany od programistów i po ich przetestowaniu itp., A sprawdzanie połączeń jest w porządku, aktualizując centralnego Gita oddziały itp., które nie są długoterminowe.

Oczekuję, że Kiln ( http://www.fogcreek.com/fogbugz/devhub ), a nawet GitHub korzystający z przepływu pracy „pull request” zadowolą doświadczonych programistów, np. Nie zacznij od niskiego poziomu, zacznij od ulepszonego proces.