Czy powinienem oczekiwać, że mój zespół będzie miał więcej niż podstawową biegłość w naszym systemie kontroli źródła?

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?

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

Przed zmianą mieliśmy tygodnie wcześniej.

Tygodnie? Zamiana kontroli źródła to wielka sprawa. Powinny istnieć miesiące wypowiedzenia prowadzące do takiej zmiany.

Z kilkoma wyjątkami większość mojego zespołu wciąż nie ma pojęcia, jak działa Git.

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

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:

• Lokalne oddziały zachęcające do eksperymentów
• Git bisect, aby łatwo wyśledzić błędy
• częste zobowiązania bez przerywania innym
• Szybkie przełączanie między oddziałami

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):

• Git z SSH w systemie Windows był częstym problemem.
• Ludzie będą ciągnąć, łączyć, ale nie przesuwać połączenia. Tak więc wykres byłby ogromnym bałaganem
• Problem z wydajnością w systemie Windows spowodował, że „status git” zajmuje 15 sekund
• Nie udało mi się ustalić, jak wyciągnąć nową gałąź. Zrobiliby „git checkout -b”, który rozgałęziałby się od wszystkiego, nad czym pracowali
• EGit in eclipse miał przytłaczające menu. Skończyło się na tym, że najpierw powiedziałem wszystkim, aby korzystali z wiersza poleceń
• W oparciu o poprzedni element, scalanie i konfigurowanie git scaletool
• Mylić o różnicach między „git add” i „git commit” i „git push”.

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

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:

  • Może dodawać pliki, zatwierdzać zmiany, wypychać i pobierać aktualizacje.
  • Może wyświetlać status i zmiany.
  • Może rozgałęziać się i scalać szybko i bez błędów.
  • Może prawidłowo korzystać z kasy.
  • Utwórz komentarze zatwierdzania, które spełniają kryteria grupy dotyczące komentarzy.
  • Różnice między kopią roboczą a archiwum.

• Z dokumentacją:

  • Dodaj użytkowników i poświadczenia dla lokalnego repozytorium.
  • zainicjuj lokalne repozytorium.
  • Administruj zdalnym repozytorium.
  • Konfiguruj ignorowane pliki, generuj pary kluczy publicznych / prywatnych PKI.
  • Przenieś i usuń pliki.
  • Użyj dwusiecznej, aby znaleźć zmianę, która wprowadziła konkretny błąd.

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.

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.

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

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.

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.

Nie; Myślę, że uzasadnione jest oczekiwanie:

1. Wykonuj codzienne zadania (zatwierdzanie, wypychanie, wyciąganie, rozgałęzianie, scalanie, dzielenie na części itp.) Bez trzymania za rękę.
2. Wykonuj nietypowe zadania bez powtarzania instrukcji. (Kilka powtórzeń jest w porządku - muszę się z kimś spotkać 2-3 razy, zanim jego nazwisko naprawdę się przylega.)

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.