Każdy programista prędzej czy później popsuje coś w repozytorium. Dobre wiadomości: Git rzadko traci dane na zawsze – reflog rejestruje każdą zmianę HEAD. Bisect skraca wielogodzinne szukanie regresji do kilku minut. Reset ma trzy tryby których mylenie kończy się bólem. Revert to bezpieczna alternatywa na publicznych branchach. Ten wpis to mapa ratunkowa.
Git hooks to skrypty uruchamiane automatycznie przy operacjach Gita. Pre-commit hook uruchomiony przed każdym commitem eliminuje klasę błędów zanim trafią do historii. Commit-msg wymusza konwencję wiadomości. Pre-push chroni zdalny branch przed broken code. Pokażę jak to skonfigurować w projekcie Magento 2 z DDEV.
Wybór workflow gitowego ma większy wpływ na produktywność zespołu niż większość decyzji technicznych. Git Flow, GitHub Flow, trunk-based development – to kompletne modele pracy, code review i deploymentu. Pokażę kiedy co stosować i co odróżnia dobry pull request od złego.
Praca z remote to codzienność w każdym zespole – ale wiele osób używa tylko git pull i ma mglistą świadomość co się właściwie dzieje. Tracking refs, różnica między fetch a pull, kiedy --force-with-lease zamiast --force, i jak naprawdę działają zdalne branche to wiedza, która ratuje przed nieodwracalnymi błędami.
Pytanie „merge czy rebase?” to jedno z najczęstszych w zespołach używających Gita. Obie strategie osiągają ten sam efekt – integrację zmian – ale produkują zupełnie inną historię. Nie ma jednej właściwej odpowiedzi, jest kontekst. Pokażę kiedy co stosować, jak działają konflikty, i dlaczego fast-forward to nie to samo co „bez merge commita”.
Historia commitów to dokumentacja projektu – czytają ją inni programiści, git bisect po niej szuka błędów, a git blame tłumaczy decyzje. Dobre wiadomości commitów, umiejętność porządkowania historii przed merge i znajomość cherry-pick oraz bisect to narzędzia, które odróżniają kogoś kto „używa Gita” od kogoś kto nim „zarządza”.
Większość programistów używa Gita jak czarnej skrzynki: coś wpisujesz, coś się zapisuje, historia jakoś działa. Dopóki coś nie pójdzie nie tak. Żeby Git przestał być magią – zacznij od zrozumienia, co naprawdę siedzi w katalogu .git/. Cztery typy obiektów: blob, tree, commit, tag. Tyle. Reszta to konsekwencje.