Statystyki z Gita: Jak mierzyć aktywność zespołu i nie wpaść w pułapkę liczb?

Czy zastanawiałeś się kiedyś, jak szybko sprawdzić, kto w Twoim zespole najczęściej commituje kod albo jak wyglądała dynamika prac w ostatnim miesiącu? Git oferuje proste, wbudowane narzędzie, które wyciąga te dane w kilka sekund – bez potrzeby instalowania zewnętrznych analityk.

Wystarczy jedno polecenie w terminalu: git shortlog -sn --all. Jeśli dodasz do niego zakres dat, otrzymasz precyzyjne podsumowanie dla konkretnego okresu, np. ostatniego sprintu czy miesiąca:

# Podsumowanie commitów za konkretny miesiąc
git shortlog -sn --all --since="2026-08-01" --until="2026-08-31"

# Szybki przegląd aktywności z ostatnich 30 dni (z adresami e-mail)
git shortlog -sne --all --since="30 days ago"

Te komendy są genialne do szybkiego przeglądu projektu, przygotowania podsumowania dla klienta czy oceny, jak rozkłada się obciążenie w zespole. Na zrzucie ekranu z mojego terminala który wrzuciłem na początku widać, jak czytelny jest taki raport w praktyce:

Czy na tej podstawie można jednak oceniać pracę programisty?

Krótka odpowiedź brzmi: nie bezpośrednio. Same liczby commitów czy linii kodu tworzą złudzenie obiektywnej metryki, ale w rzeczywistości bywają bardzo mylące. Przy takiej ocenie trzeba pamiętać o kilku rzeczach:

• Jakość vs ilość: Jeden przemyślany commit usuwający 50 linii zbędnego kodu bywa wart więcej niż 10 commitów generujących powtarzalny szablon.
• Niewidoczna praca: Git nie rejestruje czasu spędzonego na code review, debugowaniu skomplikowanych błędów, architekturze czy wsparciu innych członków zespołu.
• Grywalizacja metryk: Gdy programiści dowiadują się, że są rozliczani z liczby commitów, zaczynają rozbijać jedną zmianę na kilkanaście drobnych pchnięć.

Jednoliniowe komendy Gita to świetny termometr do badania ogólnego tętna projektu, ale nigdy nie powinny zastąpić jakościowej oceny i rozmowy z człowiekiem.