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.