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

48

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?

Joshua Smith
źródło
30
Czy firma oferowała szkolenia na temat Git?
yannis,
9
Każdy twórca, który nie jest produktywny, jest odpowiedzialnością. Zakładając, że są w ogóle produktywni, znajomość git jest nieistotna. Na koniec dnia jest to kolejne narzędzie.
MrFox,
9
Nazwałbym zrozumienie, w jaki sposób gałęzie Git działają z „podstawową biegłością” z nim…
Shauna
16
Jeśli twoi koledzy z drużyny nie mogą zrozumieć Git, masz większe problemy niż kontrola źródła.
Jordan Bentley,
4
@Caleb To nie była chwała. Daleko stąd.
Joshua Smith

Odpowiedzi:

49

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

Michael
źródło
3
Zgoda. Przeszli na system, którego prawie nikt nie rozumiał. Mądrze byłoby zaoferować szkolenie przed zmianą. Jednak czułem się swobodnie, używając Git, mając mniej niż tydzień praktyki. Nie wydaje mi się, żebym osiągał zbyt dobre wyniki, więc zastanawiam się, czy należy oczekiwać, że inni również będą ćwiczyć.
Joshua Smith
3
Czy ktoś zadał sobie trud, aby dowiedzieć się, jakie przepływy pracy miałeś i przypisać je do prymitywów, które ma do zaoferowania nowy VCS? Łatwo jest strzelać sobie w stopę za pomocą poleceń, które brzmią tak, jak zwykle, i naprawdę potrzebujesz kogoś, kto zaaranżuje coś takiego. Gdzie facet jest odpowiedzialny za tę zmianę?
Lars Viklund,
19
@JoshuaSmith Zmieniając standardy lub narzędzia programistyczne, powinieneś zawsze działać w stylu „No Child Left Behind”. Zespół może poruszać się tylko tak szybko, jak jego najwolniejszy członek, więc upewnij się, że wszystko jest tak jasne i sprowadzone do najniższego możliwego poziomu, zanim nastąpi przejście. Jasne, że możesz oznaczyć jak najwięcej osób odpowiedzialnością, jak chcesz, ale pozbycie się „pasywów” jest trudną i nieuporządkowaną rzeczą, szczególnie w odniesieniu do czegoś tak trywialnego jak narzędzie kontroli źródła.
wałek klonowy
3
Wygląda na to, że „rzuciłeś na nich GIT”, a raczej „wprowadziłem nowy system kontroli wersji” - GIT to program, który kontroluje źródła. To nie jest system kontroli źródła - wymagałby instrukcji obsługi, szkoleń, harmonogramów konserwacji, zarządzania cyklem życia itp. Powiedz mi, że masz kopie zapasowe
Mattnz,
7
Uczenie się, jak działa git, jest dość trywialne. Na pewno nie zajmuje miesiąc, aby nauczyć się go używać. Moim zdaniem prosty „Chłopaki, będziemy używać git za kilka tygodni. Poświęć kilka godzin, aby nauczyć się go używać, jest mnóstwo zasobów online.”, Byłoby więcej niż wystarczające.
Moox
34

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

Kryptic
źródło
7
@JoshuaSmith Wygląda na to, że masz wysokie oczekiwania wobec ludzi. Czy często czujesz się rozczarowany rówieśnikami?
wałek klonowy
4
@maple_shaft Rzadko jestem zawiedziony moimi rówieśnikami w tym zespole (moja ostatnia praca była inną historią). Zazwyczaj ludzie tutaj są profesjonalni i z przyjemnością współpracują. I tak, mam wysokie oczekiwania względem siebie i otaczających mnie osób. Nie jestem tym palantem. Jest to prawdopodobnie naiwne, ale uważam, że jeśli wszyscy będziemy wymagać od siebie doskonałości, nieuchronnie się poprawimy.
Joshua Smith
9
@JoshuaSmith, jeśli oczekujesz, że ludzie będą regularnie mieli czas na czytanie książek, zaryzykuję zgadnięcie: nie masz dzieci, prawda?
Kyralessa,
13
@JoshuaSmith, czy ludzie zarabiają za czytanie tych książek? Gdyby mój szef powiedział mi: „Zmieniamy technologię, oczekuję, że nauczyłeś się jej w wolnym czasie do następnego miesiąca” Byłbym bardzo wkurzony.
Matsemann,
13
@JoshuaSmith, tak, powiedziałbym tak - wszystko, co pracownik robi w swoim własnym czasie, jest dodatkowe, nieobowiązkowe. Kup więc zamianę, powinieneś podać im wystarczającą ilość informacji, aby skorzystać z narzędzia, lub wystarczająco dużo czasu w pracy, aby sami się nauczyli (zwykle jest to szkolenie, nawet jeśli jest to tylko sesja treningowa w porze lunchu). Teraz, jeśli pracownicy byli freelancerami, istnieje powód, aby szkolili się, ale nie w trakcie umowy. Pracownicy oczekują pewnych korzyści, takich jak szkolenie, i nie stresują się tym, że porzucili im taką pracę.
gbjbaanb
13

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.

DeveloperDon
źródło
11

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.

mattnz
źródło
1
I istnieje potrzeba niestandardowego treningu ... i znowu żaden Linus nie oczekuje, że ktokolwiek przyjmie wszystkie techniczne cechy gita, dlatego istnieją dwie klasy poleceń: porcelana i hydraulika.
ZJR
1
Istnieje wiele przepisów na git, jeśli wszystko, co chcesz zrobić, to migracja z przepływu pracy używanego w Brand X do przepływu pracy w Git.
Jherico
10

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

Bill Leeper
źródło
3
„Nic nie szkodzi wydajności bardziej niż grupa programistów obawiających się lub nieświadomych narzędzia”. Zakłada się, że firma oszalałaby na punkcie wprowadzenia narzędzia, w którym zespół nie został przeszkolony i nie rozumie.
Jaydee,
Firmy, szczególnie te duże, czasami muszą popychać technologię. Tt może być również jednym zespołem w organizacji, która już wykonała wstępne operacje i w pełni korzysta z narzędzia.
Bill Leeper
3

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.

Fred Thomsen
źródło
2

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.

JeffO
źródło
1

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.

pgs
źródło
To nie jest tak naprawdę odpowiedź na pytanie; pytanie brzmiało, jakiego poziomu biegłości powinien oczekiwać od innych, a nie w jaki sposób poprawia ich biegłość. Zdejmę głos negatywny, gdy powiadomisz mnie w komentarzu @MyName, że poprawiłeś swoją odpowiedź na temat.
Jimmy Hoffa
@ JimmyHoffa Myślę, że źle zrozumiałeś moją odpowiedź. Muszą być biegli w codziennych / rutynowych zadaniach i dość szybko podejmować inne zadania. Zidentyfikowałem kilka możliwych przyczyn , ale starałem się unikać zalecania jakichkolwiek działań naprawczych. Czytasz między wierszami i ekstrapolujesz, jeśli to właśnie widzisz.
pgs
Nie, pytanie brzmi: „Czy powinienem oczekiwać, że mój zespół będzie miał więcej niż podstawową biegłość ...” i nie powiedziałeś „Tak, oto dlaczego” ani nie powiedziałeś „Nie, oto dlaczego”. Odpowiedziałeś na pytanie pytaniem. Doceniam, że twoja odpowiedź jest przemyślana, a treść jest przydatna, ale nadal powinieneś odpowiedzieć na pytanie tak lub nie i spróbować powtórzyć, dlaczego uważasz, że tak lub nie ... Następnie możesz zostawić poniżej swojej odpowiedzi aktualną treść . Ma sens?
Jimmy Hoffa
@ JimmyHoffa Moja odpowiedź brzmi: „Nie, oto minimum, którego można racjonalnie oczekiwać”; Po prostu nie powiedziałem tego dokładnie.
pgs
Och, myślałem, że masz na myśli „tak”, włóż tę przedmowę i odpowiada ona na pytanie, w przeciwnym razie to po prostu nie ma sensu heh
Jimmy Hoffa