Kako razveljavite spremembe v Gitu?

Question

Accepted Answer

Git ponuja več načinov za **razveljavitev sprememb** glede na situacijo — zavrnitev nepotrjenih sprememb, razveljavitev dodajanja, popravljanje zadnjega potrjevanja, razveljavitev potrjene spremembe ali ponastavitev. Poznavanje pravega orodja za vsako situacijo je važna, praktična spretnost. ## Razveljavitev nepotrjenih sprememb (delovna mapa) ```bash git restore # discard unstaged changes to a file (revert to last commit) git checkout -- # older equivalent git restore . # discard ALL unstaged changes (careful!) git clean -fd # remove untracked files/directories ``` ## Razveljavi dodajanje (ohrani spremembe, le razvelji dodajanje) ```bash git restore --staged # unstage a file (changes stay in working dir) git reset # older equivalent ``` ## Popravi ali spremeni zadnje potrditev ```bash git commit --amend -m "New message" # change the last commit's message git commit --amend # add staged changes to the last commit # ⚠️ amend REWRITES the commit — don't amend commits already pushed/shared ``` ## Razveljavitev potrjene spremembe ```text TWO main approaches: REVERT → creates a NEW commit that undoes a previous commit (SAFE for shared history) git revert → history preserved; the undo is itself a commit RESET → moves the branch pointer BACK (rewrites history — for LOCAL commits only) git reset --soft HEAD~1 → undo commit, KEEP changes staged git reset --mixed HEAD~1 → undo commit, keep changes unstaged (default) git reset --hard HEAD~1 → undo commit AND DISCARD changes (⚠️ destructive!) ``` ## revert vs reset (ključna izbira) ```text REVERT → safe for PUBLIC/shared commits (adds a new undoing commit; doesn't rewrite history) RESET → rewrites history (only for LOCAL, unpushed commits; never on shared branches) → Rule: use REVERT to undo commits others may have; RESET only for local cleanup. ``` ## Zakaj je to pomembno Znanje, kako razveljaviti spremembe v Gitu, je važna, pogosto potrebna praktična spretnost, ker so napake in potreba po razveljavitvi dela neizogibni v razvoju, Git pa ponuja zmogljive (a situacijsko specifične) načine za okrevanje. Razumevanje **pravega orodja za vsako situacijo** je ključna spretnost: zavrnitev **nepotrjenih sprememb** (`git restore` za razveljavitev sprememb delovne mape, `git clean` za nesprejete datoteke), **razveljavitev dodajanja** (`git restore --staged` za ohranitev sprememb a razveljavitev dodajanja), **popravljanje** zadnjega potrjevanja (spreminjanje njegovega sporočila ali dodajanje vanj — s važnim opozorilom, da ne spreminjate že poslanih potrjevanj, ker to prepiše zgodovino), in razveljavitev **potrjenih** sprememb. Za razveljavitev potrjevanj je razumevanje **kritične razlike med revert in reset** posebej pomembno: **`revert`** ustvari novo potrditev, ki razveljavlja prejšnjo, in je **varno za deljeno/javno zgodovino** (ne prepiše zgodovine, zato drugih ne bo motilo), medtem ko **`reset`** premakne kazalec veje in **prepiše zgodovino**, kar je primerno le za **lokalna, neposlan potrjevanja** (in `reset --hard` je destruktiven, zavrže spremembe). Pravilo — uporabite `revert` za potrjevanja, ki jih imajo drugi, `reset` le za lokalno čiščenje — je kritično, ker prepisovanje deljene zgodovine (via reset na poslanih potrditev) povzroči resne težave za sodelavce. Znanje teh možnosti prepreči tako izgubo dela (nemarno uporabo destruktivnih ukazov) kot tudi motenje sodelovanja (prepisovanje deljene zgodovine). Ker je razveljavitev sprememb pogosta, neizogibna potreba in Git ponuja več situacijsko specifičnih pristopov s pomembnimi varnostnimi posledicami (posebej revert vs reset za deljeno zgodovino), je znanje, kako razveljaviti spremembe v Gitu — pravo orodje za vsak scenarij in ključna razlika med revert in reset — dragoceno, pogosto uporabljeno praktično znanje za zaupno in varno delo z Gitom, spretnost, ki spremeniti tesnobo napak v rutinsko okrevanje, hkrati pa se izogiba resni nevarnosti prepisovanja deljene zgodovine.