Analiza logów Git: ukryte dane o zespole i metrykach projektu

Jak wydobyć ukryte dane o zespole z logów Git: od osobistych nawyków do metryk projektu

Analiza logów Git pozwala ujawnić nieoczywiste wzorce w pracy zespołu, począwszy od danych osobowych developerów, aż po strukturę projektu. Te metody, choć nie dają 100% dokładności, zapewniają unikalne insighty dla technical leadów i inżynierów DevOps.

Wydobywanie danych osobowych poprzez adresy email

Adresy email w commitach często zawierają informacje wykraczające poza kontekst pracy. Pierwszym krokiem jest pobranie logów za pomocą komendy:

git --no-pager log --raw --numstat --oneline --all --reverse --date=iso-strict --pretty=format:"%ad>%aN>%aE>%s" > log.txt

Po otrzymaniu pliku można przystąpić do analizy.

Określenie roku urodzenia

Filtrowanie osobistych adresów email (np. gmail.com, wp.pl, interia.pl) i wyszukiwanie sekwencji cyfrowych w loginach pozwala przypuszczać rok urodzenia. Kryteria: różnica z bieżącym rokiem powinna wynosić od 18 do 70 lat.

Wykrywanie projektów hobbystycznych

Wykluczając techniczne emaile GitHub, można utworzyć linki do profili developerów, co pomaga odkryć ich zewnętrzne aktywności. Jest to przydatne do oceny zaangażowania i ekspertyzy.

Analiza sprzętu

W macOS email domyślnie może zawierać nazwę urządzenia (np. Macbook-Air-Alex). Pozwala to klasyfikować użytkowników:

• Właściciele MacBook Pro;
• Właściciele MacBook Air;
• Pozostali (inne systemy).

Choć bezpośrednia korelacja z rolą (frontend/backend) nie jest udowodniona, dane mogą wskazywać na korporacyjne standardy.

Badanie infrastruktury sieciowej

Gdy nazwa urządzenia jest niedostępna, macOS może wstawić lokalny adres IP. Analiza zakresów adresów (np. końcówki .49, .50, .51) pozwala przypuszczać liczbę urządzeń w sieci, choć dokładność zależy od konfiguracji DHCP.

Analiza wzorców commitów i workflow

Częstotliwość i charakter commitów ujawniają szczegóły grafiku pracy i składu zespołu.

Tworzenie grafiku urlopów

Długie przerwy w commitach (tygodnie lub miesiące) mogą wskazywać na urlop, przeniesienie do innego działu lub zmianę pracy. W zespołach z ustalonymi procesami daje to względnie dokładny obraz. Team leaderzy, poświęcający więcej czasu spotkaniom, mogą wykazywać minimalną aktywność, co również jest wskaźnikiem.

Obliczanie pozostałych dni urlopowych

Na podstawie przepracowanych lat (zakładając standardowe 28 dni urlopu rocznie) i wykrytych przerw można oszacować niewykorzystane dni. Ważne jest uwzględnienie zmiany adresów email, która może sygnalizować przepisanie w innej firmie.

Wykrywanie developerów wielojęzycznych

Wyszukiwanie błędów lingwistycznych w commit message pomaga zidentyfikować native speakerów różnych języków. Przykłady wzorców:

• Użycie „and etc” zamiast „, etc” (rusycyzm w angielskim);
• Przecinek przed „and” w wyliczeniach (angielska interpunkcja);
• Literówki typu „ano” zamiast „año” (hiszpański).

Katalogowanie takich błędów pozwala przypuszczać tło kulturowe, co jest istotne dla rozproszonych zespołów.

Określenie lokalizacji biura

Łączenie danych o strefie czasowej, email i wzorcach językowych pomaga wykryć główne miejsce pracy większości developerów. Choć metoda jest mniej dokładna w erze pracy zdalnej, jest przydatna do analizy historycznej lub oceny koncentracji zespołu.

Techniczne insighty i metryki projektu

Logi Git zawierają informacje o stanie bazy kodu i infrastrukturze.

Kandydaci do refaktoryzacji

Używając heurystyk, można automatycznie wykrywać problematyczne pliki:

• Duży rozmiar (ponad 600 linii);
• Częste zmiany (ponad 50 zadań);
• Wykluczenie konfigów i testów (po rozszerzeniach .json, .xml).

Takie podejście, choć przybliżone, często wskazuje na rzeczywiste punkty wzrostu długu technicznego.

Wykrywanie infrastruktury

Zapisy o scalaniu gałęzi lub PR mogą zawierać zewnętrzne adresy repozytoriów (np. linki do GitHub lub Bitbucket). Analiza tych danych odsłania historię migracji między systemami przechowywania kodu.

Identyfikacja systemów przechowywania

Różnice syntaktyczne w logach pozwalają określić używaną platformę:

• GitHub: „Merge pull request #...”;
• Bitbucket: „Pull request #...”;
• Wariacje cudzysłowów wokół nazw gałęzi.

To pomaga śledzić przejścia między narzędziami.

Ocena rozmiaru zespołu i backlog

Numery zadań z commit message służą jako podstawa dla metryk produktywności.

Obliczanie tempa pracy

Algorytm oceny:

• Wydobycie numerów zadań (np. HABR-123) z commitów;
• Grupowanie po datach do określenia wolumenu wykonanych zadań;
• Policzanie unikalnych loginów developerów – bieżąca grupa robocza;
• Obliczenie średniej liczby zadań na osobę za okres.

Określenie tempa tworzenia zadań

Analiza wzrostu numerów zadań w tygodniu daje wskaźnik „tempa tworzenia”. Dzieląc go przez „średnią liczbę zadań na osobę”, można oszacować całkowity rozmiar działu, w tym analityków i testerów.

Walidacja danych poprzez release

Częste release i hotfixy zapewniają aktualność numerów zadań, ponieważ są tworzone bezpośrednio przed naprawą. To zmniejsza błąd związany z backlogiem.

Ocena rozmiaru backlogu

Analiza historyczna pozwala śledzić, kiedy zadania zostały stworzone i kiedy podjęte do pracy. Procent zadań z backlogu w całkowitym wolumenie za okres daje obraz obciążenia zespołu i planowania.

Co jest ważne

• Analiza logów Git – potężne narzędzie do uzyskiwania insightów o zespole i projekcie, ale wymaga krytycznej interpretacji ze względu na probabilistyczny charakter metod.
• Adresy email i wzorce commitów mogą ujawniać dane osobowe, co podnosi kwestie etyki i bezpieczeństwa – używaj takich metod tylko w kontekście korporacyjnym z zachowaniem polityk.
• Metryki oparte na numerach zadań (rozmiar zespołu, backlog) są przydatne do zarządzania projektami, ale ich dokładność zależy od dyscypliny prowadzenia trackera i częstotliwości release'ów.
• Analiza lingwistyczna commit message pomaga w rozproszonych zespołach w zrozumieniu różnorodności kulturowej i potencjalnych barier komunikacyjnych.
• Automatyczne wykrywanie kandydatów do refaktoryzacji przez heurystyki (rozmiar pliku, częstotliwość zmian) jest efektywne do priorytetyzacji długu technicznego, ale powinno być uzupełnione code review.

— Editorial Team