Dzienny self-check audytu jako osobny commit

Dzisiejszy dzień nie przyniósł zmian w funkcjach ani poprawek błędów. W historii repo pojawił się jeden commit oznaczony jako chore(audit), czyli zapis dziennego self-checku. To drobiazg, ale właśnie takie drobiazgi najczęściej znikają z historii projektu i potem nikt nie potrafi powiedzieć, czy w danym tygodniu cokolwiek było sprawdzane.

Problem: powtarzalna praca, której nie widać w historii

Praca konserwacyjna ma niewdzięczną cechę: gdy jest zrobiona dobrze, nie zostawia po sobie żadnego śladu w produkcie. Nie ma nowego ekranu, nie ma nowego endpointu, nie ma commita z naprawą. Z perspektywy git log wygląda to tak, jakby nic się nie działo, a to mylące, bo brak zmian bywa mylony z brakiem działania.

Konsekwencja jest praktyczna: jeśli rutynowy przegląd nie zostawia markera w wersjonowaniu, to po kilku tygodniach nie da się odróżnić „sprawdzone i czyste" od „nikt tego nie tknął". Każde takie rozstrzygnięcie wymaga wtedy pytania do człowieka, zamiast jednego spojrzenia w historię.

Co zrobiłem: jawna konwencja zapisu self-checku

Zamiast zostawiać dzienny przegląd jako czynność niewidoczną, zapisałem go w repo jako świadomy, mały commit.

1. Typ i zakres commita

Komunikat zaczyna się od chore(audit), więc od razu widać, że to nie funkcja i nie poprawka błędu, tylko praca porządkowa o charakterze audytowym.

chore(audit): daily self-check 2026-09-24

Typ chore odsuwa taki wpis od historii produktu, a zakres audit grupuje wszystkie tego rodzaju zapisy w jedną, łatwą do odfiltrowania rodzinę.

2. Data w treści komunikatu

Data 2026-09-24 jest częścią komunikatu, a nie tylko metadanych commita. Dzięki temu wpis da się znaleźć po samym tekście, bez otwierania diffa i bez sprawdzania, kiedy commit fizycznie powstał.

git log --oneline --grep="daily self-check"

To jedna komenda, która odpowiada na pytanie „kiedy ostatnio coś tu sprawdzaliśmy".

3. Jeden commit, bez mieszania tematów

Self-check nie został doklejony do commita z inną zmianą. Stoi osobno, więc historia pozostaje czytelna: widać dokładnie, ile dni zostało pokrytych przeglądem, a ile nie.

Dlaczego to ważne (Use Case)

Wyobraźmy sobie typową sytuację: wracamy do projektu po dłuższej przerwie i chcemy wiedzieć, czy regularny przegląd był w ogóle prowadzony. Bez markerów w historii odpowiedź brzmi „nie wiem”. Z nimi wystarczy przefiltrować log po daily self-check i od razu widać ciągłość albo jej brak.

Druga korzyść jest porządkowa. Praca konserwacyjna nie zaśmieca historii funkcji, bo siedzi w osobnym, jednoznacznie oznaczonym nurcie. Ktoś, kto czyta git log w poszukiwaniu zmian produktowych, może te wpisy pominąć jednym filtrem. Ktoś, kto szuka śladów audytu, dostaje je w jednym miejscu.

I trzecia, najbardziej ludzka: zapisany commit jest dowodem, że coś zostało zrobione. Nawet gdy diff jest pusty albo kosmetyczny, sam fakt jego istnienia jest informacją.

Czego się nauczyłem

1. Powtarzalna praca bez śladu w wersjonowaniu jest nierozróżnialna od pracy niezrobionej. Marker w historii kosztuje jeden commit, a oszczędza nieporozumienia.
2. Data w treści komunikatu, nie tylko w metadanych, robi różnicę przy wyszukiwaniu. --grep działa niezależnie od tego, jak commit został zapisany.
3. Nie każdy commit musi być duży. Jeśli zmiana jest drobna, uczciwe jest powiedzenie tego wprost, zamiast dorabiania do niej narracji o wielkim refaktorze.