Kdaj in kako bi moral prepisati Git zgodovino?

Question

Accepted Answer

Git ti omogoča **prepisovanje zgodovine** — spreminjanje, rebasiranje, stiskanje ali odstranjevanje commitov — da očistiš commite ali rešiš težave. To je zmogljivo, vendar se mora narediti previdno: prepisovanje **skupne** zgodovine povzroči resne težave, zato so pravila glede tega kritična. ## Načini prepisovanja zgodovine ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## Zlato pravilo ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## Legitimne rabe prepisovanja (lokalno) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## Če moraš prepisati skupno zgodovino (redko) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## Zakaj je to pomembno Razumevanje kdaj in kako prepisati Git zgodovino je pomembno znanje za izkušene razvijalce, ker je prepisovanje zgodovine **zmogljivo vendar nevarno**, in razumevanje pravil — posebej glede skupne zgodovine — prepreči resne težave, hkrati pa omogoči legitimno čiščenje. Znanje **načinov prepisovanja** (amend za zadnji commit, interactive rebase za stiskanje/prepisovanje sporočil/spreminjanje vrstnega reda, rebase za linearno zgodovino, reset, filter-repo za obsežne spremembe) in da **spremenijo heše commitov** (ustvarijo nove commite) je temelj. Najbolj kritično je razumevanje **zlatega pravila — nikoli ne prepisuješ skupne/potisnjene zgodovine** — je bistveno, ker prepisovanje spremeni heše, kar povzroči, da se tvoja zgodovina razlikuje od sodelavčeve (ki imajo še stare commite), kar vodi do podvojenih, konfliktnih in boleče usklajevanja; prepisovanje skupne zgodovine je resna motnja, ki ji to pravilo prepreči, pri čemer je **revert** (varen nov undoing commit) pravilni pristop za skupne veje namesto tega. Razumevanje **legitimnih lokalnih rab** (čiščenje WIP commitov pred PR, popravljanje napak pred potiskom, rebasiranje za ohranitev linearne zgodovine pred deljenjem — vse na lokalnih, nepotisnjenih commitih) pojasni kdaj je prepisovanje primerno in dragoceno. Krucialnih je varnostna niansa: če je bil **skrivnost commitan in potisnan**, je prepisovanje zgodovine za njeno odstranitev nezadostno — skrivnost je že izpostavljena in jo je treba **rotirati** (pomembna točka iz realnega sveta za varnost). Znanje kako **ravnati z redko potrebnim prepisom skupne zgodovine** (usklajevanje tima, `--force-with-lease` namesto `--force`, vsi se ponovno sinhronizirajo) odraža zrelo presojo. Ker je prepisovanje zgodovine zmogljivo vendar povzroči resne težave pri nepravilni rabi na skupni zgodovini, in ker je razumevanje zlatega pravila, legitimnih rab in varnih praks bistveno za odgovorno uporabo, je razumevanje kdaj in kako prepisati Git zgodovino pomembno znanje za izkušene razvijalce — tema, kjer razumevanje varnostnih pravil (posebej nikoli ne prepisuješ skupne zgodovine) prepreči prave katastrofe pri sodelovanju, kar odraža presojo, ki se pričakuje za izkušene vloge pri delu z Gitom v timih.