Koledzy, którzy nie robią commitów
Jak rozpoznać developera, który trzyma cały projekt w folderze „final_v2_REALLY_FINAL” i dlaczego git log wygląda jak pustynia po apokalipsie.
uid zero
IT · SysOps · Helpdesk
Stand-up, 9:02
Prowadzący daily pyta:
„Co u Ciebie wczoraj?”
Programista z zespołu patrzy w sufit jak na egzaminie z filozofii:
„Ogólnie poszło dobrze. Refaktor. Trochę testów. Jeszcze nie pushowałem, bo chcę to dopracować.”
Pushował. W sensie — nie. Od wtorku. Od zeszłego wtorku.
Na czacie firmowym wisi wiadomość sprzed trzech dni:
„Zaraz wrzucę, tylko jeszcze formatowanie”
Formatowanie trwa dłużej niż remont autostrady A2.
Archeologia bez commitów
W każdym zespole jest taki człowiek. Znasz go po objawach:
- Folder na pulpicie:
projekt_final,projekt_final_v2,projekt_final_v2_NAPRAWDE_OSTATECZNY - Na daily mówi „prawie gotowe” jak mantra
- Przy merge requestcie: 47 plików, 12 000 linii, zero opisu
- Jak zapytasz o branch: „A ja pracuję lokalnie, żeby nie psuć wam repo”
Dzięki. Nie psujesz repo. Izolujesz je w swoim laptopie jak skarb w bunkrze.
„Jutro zrobię commit”
Piątek, 16:58.
— „Wrzucisz dzisiaj ten fix do produkcji?”
— „Jasne, wieczorem siądę spokojnie.”
Weekend.
Poniedziałek, 9:00.
— „I jak z tym fixem?”
— „A, nie zdążyłem. Ale mam już wszystko u siebie. Jak coś — podeślę zipa.”
Zipa.
W 2026.
Człowiek wysłałby go gołębiem pocztowym, gdyby poczta nie blokowała załączników większych niż CV juniora.
Merge request z piekła rodem
W końcu ktoś klika „Create pull request”.
Tytuł: fix
Opis: (pusty)
Zmiany obejmują:
- refaktor całego modułu płatności
- nowy sidebar
- trzy pliki konfiguracyjne
- przypadkowy
console.log("tu jestem")w 14 miejscach - zakomentowany kod z TODO z 2019
- i jedną linijkę, o którą prosiłeś: zmiana koloru przycisku
Reviewer patrzy na diff jak na serial — nie wiadomo, kiedy skończyć.
Komentarz po godzinie:
„Proszę podzielić na mniejsze MR-y.”
Odpowiedź:
„Nie da się, bo to jedna spójna całość.”
Spójna całość jak rosół po tygodniu w lodówce — technicznie jedna rzecz, ale nikt nie chce tego dotykać.
Teoria wielkiego braku commitów
Na retro wymyślono klasyfikację:
| Typ | Zachowanie | Poziom zagrożenia |
|---|---|---|
| Kolekcjoner WIP | 200 niezacommitowanych plików, „jeszcze nie gotowe” | Średni |
| Filozof Git-a | „Commit to za wcześnie, muszę poczuć kod” | Wysoki |
| Zombie branch | feature/lokalne-zmiany żyje od 8 miesięcy | Krytyczny |
| Wróżka zipów | wysyła archiwum zamiast pusha | Apokalipsa |
Combo wszystkich typów naraz to osiągnięcie platynowe.
Co robi reszta zespołu
Reszta zespołu:
git pull
# Already up to date.
Ten jeden programista:
# ...cisza...
# ...dźwięk myszy...
# Ctrl+S x 400
Na czacie:
„Masz konflikt z mainem.”
Odpowiedź:
„U mnie działa.”
U Ciebie. Na Twoim komputerze. W Twojej rzeczywistości równoległej.
Happy end? Nie bardzo
Po eskalacji tech lead każe: commit co 2 godziny albo przynosisz laptop na biurko.
Pojawiają się commity:
wip
Następny:
wip2
Trzeci:
asdfgh
Git log wygląda jak lista zakupów człowieka po trzech nocnych zmianach.
Ale przynajmniej coś jest w repo.
Na retro ustalacie zasadę: małe commity, sensowne opisy, code review przed mergem.
Kolejnego dnia na daily:
„Wczoraj dużo kodowałem. Jeszcze nie pushowałem.”
I koło się zamyka jak while(true) bez break.
Jeśli rozpoznajesz ten schemat — nie jesteś sam.
Jeśli to Ty — zrób commit. Teraz. Naprawdę. Zanim ktoś znowu dostanie zipa z hasłem w osobnej wiadomości.