Moja firma przeszła z Subversion na Git około trzy miesiące temu. Przed zmianą mieliśmy tygodnie wcześniej. Ponieważ nigdy wcześniej nie korzystałem z Gita (ani żadnego innego DVCS), czytałem Pro Git i spędziłem trochę czasu na tworzeniu własnych repozytoriów i zabawie, więc po zmianie mogłem pracować z minimalnym bólem. Teraz domyślnie jestem „facetem od gitów”.
Z kilkoma wyjątkami większość mojego zespołu wciąż nie ma pojęcia, jak działa Git. Na przykład nadal uważają oddziały za kompletne kopie kodu źródłowego, a nawet posuwają się tak daleko, że klonują repozytorium do wielu folderów (po jednym na oddział). Na ogół patrzą na Gita jako przerażającą czarną skrzynkę.
Biorąc pod uwagę fundamentalny charakter kontroli źródła w naszej codziennej pracy (nie wspominając o absurdalnej mocy, jaką daje nam Git), jestem zdania, że każdy twórca, który nie osiąga określonego poziomu biegłości w tym zakresie, jest odpowiedzialny .
Czy powinienem oczekiwać, że mój zespół przynajmniej zrozumie, jak działa Git wewnętrznie i jak go używać poza najbardziej podstawowymi operacjami ściągania / scalania / wypychania? A może po prostu robię coś z niczego?
źródło
Odpowiedzi:
Profesjonalizm w naturalny sposób dyktuje, że programista zapozna się ze standardowymi narzędziami swojego zespołu, nawet jeśli są nowe i nieznane (lub nawet niepożądane).
Jednak kilka rzeczy w twoim poście daje mi pauzę.
Tygodnie? Zamiana kontroli źródła to wielka sprawa. Powinny istnieć miesiące wypowiedzenia prowadzące do takiej zmiany.
Twoja firma przeszła na system kontroli źródła, który niewielu, jeśli ktokolwiek, zrozumiał w tym czasie?
Jeśli nie ma innego kontekstu, wygląda na to, że cały ruch był źle przemyślany (ruch, a nie wybór - jestem wielkim fanem git).
źródło
Wprowadzamy Git tam, gdzie pracuję, i naturalnie pojawił się opór. To był nowy projekt, więc teraz utrzymujemy dwa repozytoria.
Częściowym problemem jest to, że ludzie nie zobaczą korzyści z przejścia na inny SCM, gdy ten, którego używali, działa dla nich. Pomogło nam, gdy usiedliśmy z naszym zespołem na kilku godzinnych sesjach, podczas których pokazywaliśmy przypadki użycia z naszych projektów i jak Git to ułatwił. Na przykład rzeczy, które nam pomogły:
itd. Każdy z nich rozwiązał problem, który napotkaliśmy w naszym poprzednim SCM, dzięki czemu ludzie mogli bardziej docenić Git.
Inną rzeczą jest to, że nie można oczekiwać, że ludzie pójdą i przeczytają o tym książki, ponieważ niewielu to zrobi. Może muszą wykonać pracę, mieć inne obowiązki lub z wielu innych powodów.
Tak więc, jako „ekspert Git”, musisz usiąść i ułatwić ludziom korzystanie z niego. Chcą pisać kod, a nie bawić się w swój system SCM.
Interfejs CLI Git to tajemnicze i trywialne problemy (dla ciebie i dla mnie) będą blokować ludziom pracę. Oto, co wydarzyło się w naszym zespole (pamiętaj, że są to dość kompetentni programiści):
Nadal odczuwamy pewien opór, ale ludzie zdecydowanie widzą korzyści. Bardzo ważne jest, aby mieć kilka osób z Git do poradnictwa i być gotowym do pomocy. Również unikałbym uczenia fajnych rzeczy, takich jak reset / rebase / - popraw / etc. ponieważ większość ludzi korzysta z Git jak SVN, lepiej pozwolić im odkryć go, jeśli sobie tego życzą.
źródło
Biegły kontra Git-mania
Termin taki jak podstawowa biegłość może oznaczać różne rzeczy dla różnych ludzi. Wydaje się, że wiele osób ma git-manię (nie dlatego, że jest w tym coś złego). Wielu z nas zostało poważnie poparzonych przez niechęć naszych i innych ludzi do kontroli źródła.
Dlaczego to ma znaczenie (tak wiele)
Narzędzia kontroli źródła są krytyczne, ponieważ niewłaściwe użycie może spowolnić nie tylko jedną osobę, ale cały zespół. Niewłaściwe używanie Git powinno być mniej problematyczne niż niewłaściwe używanie SVN, CVS i innych systemów. Historycznie nieudolne korzystanie z systemów blokujących pliki było szczególnie problematyczne, a firmy zatrudniały dyskretne zespoły budujące, aby gdy ktoś wpadł w kłopoty, był biegły ekspert, który prawie nie kontrolował źródła, kto mógł wyleczyć ranę z repozytorium. To częściowo tłumaczy część pasji, którą kryje się za git.
Jak wygląda podstawowa biegłość?
Niektóre konkretne kryteria obejmują:
Bez odniesienia do dokumentacji:
Z dokumentacją:
Solidny mentalny model git i zarządzanego kodu ma kluczowe znaczenie dla uniknięcia błędów.
Co byś dodał za zaawansowaną biegłość / wiedzę specjalistyczną?
Płynne korzystanie jest niezbędne dla programistów i być może niektórych członków Twojego zespołu. Narzędzia takie jak Git są narzutowe i powinny być nauczone do poziomu, w którym mogą być prawie automatyczne. Minimalizowanie czasu i rozproszenie uwagi przy użyciu poleceń git powtarzanych tysiące razy w roku ma wysoką wartość.
Zawsze znajdą się członkowie twojego zespołu, którzy będą zaawansowanymi użytkownikami i używają prawie każdego polecenia z prawie każdą opcją. Zalecam, aby członkowie zespołu byli zachęcani do ciągłego uczenia się git (i innych narzędzi), dopóki ROI na naukę nie spadnie poniżej wartości robienia czegoś innego w projekcie, przy czym głównym ograniczeniem jest dotrzymywanie kroku przypisanym elementom do wypalania z bieżącego sprint.
źródło
GIT jest sprawiedliwym narzędziem do wykonywania pracy, a jednym z jego największych problemów jest to, że wielu ewangelistów GIT oczekuje, że wszyscy użytkownicy GIT znajdą się pod maską ekspertów rozumiejących najdrobniejsze punkty, jak to działa. To największa słabość GIT - aby z niego skorzystać, musisz wiedzieć, jak to działa. Z GIT nie ma żadnych przepisów, oczekuje się, że będziesz ekspertem GIT lub go nie użyjesz. Wspaniale jest, gdy czytasz Pro-GIT, twoja organizacja potrzebuje guru „goto” GIT (lub dwóch), aby zmaksymalizować inwestycje, ponieważ nie każdy programista chce zostać Guru GIT - i to jest w porządku.
Zespół musi wiedzieć, jak korzystać z GIT (w rzeczywistości musi tylko wiedzieć, jak korzystać z części GIT, których wymaga przepływ pracy), a nie jak działa GIT. Szkoda, że każdy programista zna każdy szczegół na temat każdego używanego narzędzia. Jeśli nie masz książki kucharskiej, która obsługuje Twój przepływ pracy, nie wdrożyłeś GIT, zrzuciłeś ją na programistów.
Nie daję małpom, jak działa GIT, o ile wiem, jak sprawić, by git działał dla mnie.
źródło
Tak.
Bez względu na to, jakie narzędzie zdecydowała „firma”, zespół programistów powinien poświęcić trochę czasu na naukę prawidłowego korzystania z tego narzędzia. Nic nie szkodzi wydajności bardziej niż grupa programistów obawiających się lub nieświadomych narzędzia. Jeśli używają go niewłaściwie lub działają przeciwko niemu, pojawią się problemy, a po przejściu do faceta zostaniesz poproszony o posprzątanie bałaganu.
Git jest trudnym przejściem dla wielu, więc obowiązkowa sesja treningowa może być w porządku. To powinno pomóc w rozwiązaniu wielu problemów, które ludzie mają.
źródło
Używałem Gita tylko w środowisku osobistym, a nie profesjonalnym i chociaż podoba mi się jego moc i pomysł bardziej zdecentralizowanej kontroli źródła, ma on poważne problemy. Git ma nieszczelną abstrakcję i wymaga wielu poleceń do robienia prostych rzeczy (na przykład, aby dokonać zmiany: git add, git commit, a następnie git push). Brakuje również niektórych dokumentów i / lub jest mylących, jak w przypadku opisu polecenia rebase ... „Przekazywanie lokalnych portów do zaktualizowanego nagłówka”. Nie mam pojęcia, co to znaczy, i chociaż teraz wiem, że możesz przenosić zatwierdzenia i przepisywać z nim historię (kolejna irytacja ... dlaczego miałbyś to robić ???) Nigdy bym tego nie odgadł po tym poleceniu opis. Myślę, że trochę czytania ze strony twojego zespołu, a trochę więcej szkolenia zapewnionego przez ciebie jest w porządku.
źródło
Szkolenie i zrozumienie są minimalnymi wymaganiami. Osoba odpowiedzialna powinna była upewnić się, że istnieje plan wykorzystania tego przez twój zespół. Nie wprowadziłbyś nowego języka programowania bez wytycznych. Szkolenie kierowców jest znacznie bardziej efektywne, jeśli uwzględnione zostaną ustalone zasady ruchu drogowego.
źródło
Nie; Myślę, że uzasadnione jest oczekiwanie:
Jeśli nie mogą zrobić nr 1, to część treningowa twojego wdrożenia była prawdopodobnie niewystarczająca. Jeśli nie potrafią zrobić # 2, najpierw upewnij się, że wyjaśnisz wszystko wystarczająco jasno, zanim się zbyt zdenerwujesz.
źródło