Git powinien być ćwiczony jako system współpracy
Samodzielne wykonanie git add, commit i push pokazuje składnię, ale nie uczy pracy z historią tworzoną przez kilka osób. Najwięcej pytań pojawia się przy rozbieżnych branchach, konflikcie, poprawianiu wcześniejszego commita i wyborze sposobu integracji zmian. Te sytuacje trzeba zaprojektować w scenariuszu szkolenia.
Laboratorium może składać się z osobnej maszyny dla każdego uczestnika i wspólnego zdalnego repozytorium przygotowanego wyłącznie na zajęcia. Kod nie musi pochodzić z produktu firmy. Niewielki projekt z testami i kilkoma zależnymi plikami wystarczy, by konsekwencje zmian były widoczne.
Tożsamość i uwierzytelnienie są częścią konfiguracji
Każde konto powinno mieć własną nazwę użytkownika i adres używany w commitach. Dzięki temu historia pokazuje, kto wykonał zmianę, a prowadzący może omówić znaczenie autorstwa i osoby zatwierdzającej. Nie warto używać jednego współdzielonego klucza SSH ani tokenu dla całej grupy, ponieważ zaciera to odpowiedzialność i utrudnia unieważnienie dostępu.
Dane dostępowe powinny działać tylko przez okres szkolenia. Jeśli ćwiczenia obejmują podpisywanie commitów, ochronę brancha albo pull requesty, potrzebna jest usługa, która rzeczywiście obsługuje te mechanizmy. Do nauki podstaw wystarczy prostszy zdalny serwer Git. Dobór narzędzia powinien wynikać z programu, nie z przyzwyczajenia do konkretnej platformy.
Dobry konflikt nie jest przypadkiem
Konflikt przygotowany do ćwiczenia powinien mieć jasną przyczynę i kilka sensownych rozwiązań. Dwie osoby mogą zmienić ten sam fragment konfiguracji z inną intencją, a następnie wspólnie ustalić wersję końcową. Prowadzący ocenia nie tylko poprawność pliku, lecz także zrozumienie różnicy między zawartością branchy i sposób uzasadnienia decyzji.
Przypadkowy konflikt w dużym pliku generowanym automatycznie uczy głównie ostrożności, ale niewiele mówi o modelu Git. Na szkoleniu lepiej użyć krótkiego kodu, testu albo dokumentu, w którym uczestnik może porównać obie strony i świadomie zbudować rezultat.
Pomyłka powinna pozostawić ślad do analizy
Wydzielone repozytorium pozwala bezpiecznie przećwiczyć reset, revert, rebase i odzyskiwanie commita przez reflog. Przed wykonaniem polecenia uczestnik powinien przewidzieć, co stanie się z indeksem, katalogiem roboczym i historią. Po operacji porównuje przewidywanie z wynikiem.
Nie chodzi o zapamiętanie listy „niebezpiecznych” komend. Ważniejsze jest rozróżnienie zmian lokalnych od opublikowanych oraz operacji, która przepisuje historię, od commita odwracającego wcześniejszą zmianę. Laboratorium można przywrócić, ale najpierw warto odczytać graf i ustalić, dlaczego repozytorium znalazło się w danym stanie.
Scenariusz powinien mieć punkty kontrolne
Po każdym etapie można sprawdzić obserwowalny stan: nazwę aktualnego brancha, relację do zdalnego repozytorium, wynik testów i graf commitów. Automatyczny skrypt może potwierdzić, czy oczekiwany commit istnieje i czy pliki zawierają właściwy rezultat. Nie powinien oceniać stylu współpracy wyłącznie na podstawie końcowego drzewa.
Prowadzący potrzebuje także sposobu rozpoznania, czy problem dotyczy Git, uprawnień do repozytorium, sieci czy samego projektu. Wspólna wersja klienta, ta sama konfiguracja i identyczny punkt startowy znacznie skracają diagnozę. Panel trenera lub dostęp do wybranego stanowiska pomaga wtedy, gdy uczestnik wyrazi zgodę na wsparcie.
Reset nie może niszczyć pracy całej grupy
Każdy uczestnik powinien mieć własny fork, repozytorium lub zestaw branchy, które można odtworzyć bez ingerencji w ćwiczenia innych. Wspólne zadania zespołowe wymagają osobnych grup i kopii repozytorium bazowego. Skrypt resetujący powinien usuwać wyłącznie zasoby należące do wskazanego ćwiczenia.
Przed kolejną edycją szkolenia warto odtworzyć cały przebieg z czystych kont. Pozostawione branche, tagi i reguły ochrony potrafią zmienić zachowanie instrukcji. Konfiguracja z poprzedniej grupy nie jest stanem bazowym, nawet jeśli projekt na pierwszy rzut oka wygląda tak samo.
Po warsztacie zachowaj historię, która ma wartość dydaktyczną
Uczestnik może otrzymać kopię repozytorium z własnymi commitami, jeśli nie zawiera ono informacji firmowych ani danych innych osób. Przydatne są również przykładowe rozwiązania, grafy historii i krótki opis decyzji podjętych podczas konfliktu. Tymczasowe tokeny oraz konta laboratoryjne powinny zostać wyłączone.
Osobne VM utworzone z jednej konfiguracji bazowej pozwalają przygotować identycznego klienta Git, narzędzia do wizualizacji historii i projekt startowy. Dzięki temu szkolenie koncentruje się na modelu pracy z historią, a nie na różnicach między lokalnymi instalacjami.