Chapters ▾ 2nd Edition

2.4 Git Basics - Dinge ongedaan maak

Dinge ongedaan maak

Op enige stadium wil jy dalk iets ongedaan maak. Hier sal ons 'n paar basiese instrumente hersien om veranderings wat jy gemaak het, ongedaan te maak (undo). Wees versigtig, want jy kan nie altyd van hierdie aksies terugrol (revert) nie. Dit is een van die min areas in Git waar jy dalk werk kan verloor as jy dit verkeerd doen.

Een van die algemeenste ongedaan-maak aksies vind plaas wanneer jy te vroeg vaslê (commit) en moontlik vergeet om sommige lêers by te voeg, of jou vasleggingsboodskap (commit message) opmors. As jy daardie vaslegging (commit) wil oordoen, maak die bykomende veranderings wat jy vergeet het, berei hulle voor (stage), en lê weer vas (commit) deur die --amend opsie te gebruik:

$ git commit --amend

Hierdie opdrag neem jou voorbereidingsarea (staging area) en gebruik dit vir die vaslegging (commit). As jy geen veranderings sedert jou laaste vaslegging (commit) gemaak het nie (byvoorbeeld, jy voer hierdie opdrag uit onmiddellik na jou vorige vaslegging), sal jou momentopname (snapshot) presies dieselfde lyk, en al wat jy sal verander, is jou vasleggingsboodskap (commit message).

Dieselfde vasleggingsboodskap-redigeerder (commit-message editor) maak oop, maar dit bevat reeds die boodskap van jou vorige vaslegging (commit). Jy kan die boodskap wysig soos altyd, maar dit oorskryf (overwrites) jou vorige vaslegging (commit).

As 'n voorbeeld, as jy vaslê (commit) en dan besef jy het vergeet om die veranderings voor te berei (stage) in 'n lêer wat jy by hierdie vaslegging (commit) wou voeg, kan jy so iets doen:

$ git commit -m 'Initial commit'
$ git add forgotten_file
$ git commit --amend

Jy eindig met 'n enkele vaslegging (commit) — die tweede vaslegging vervang die resultate van die eerste.

Note

Dit is belangrik om te verstaan dat wanneer jy jou laaste vaslegging wysig (amend), jy dit nie soseer regmaak nie, as wat jy dit heeltemal vervang met 'n nuwe, verbeterde vaslegging (commit) wat die ou vaslegging uit die pad stoot en die nuwe vaslegging in sy plek plaas. Effektief is dit asof die vorige vaslegging (commit) nooit gebeur het nie, en dit sal nie in jou bewaarplek (repository) se geskiedenis wys nie.

Die duidelike waarde van die wysiging (amending) van vasleggings (commits) is om klein verbeterings aan jou laaste vaslegging (commit) aan te bring, sonder om jou bewaarplek (repository) se geskiedenis te bemors met vasleggingsboodskappe (commit messages) in die vorm van, “Oeps, vergeet om 'n lêer by te voeg” of “Vervlaks, 'n tikfout in laaste commit reggemaak”.
Note

Wysig (amend) slegs vasleggings (commits) wat nog plaaslik (local) is en nie iewers heen opgestuur (pushed) is nie. Om voorheen opgestuurde (pushed) vasleggings (commits) te wysig (amend) en die tak (branch) met dwang op te stuur (force push), sal probleme vir jou medewerkers veroorsaak. Vir meer inligting oor wat gebeur wanneer jy dit doen en hoe om te herstel as jy aan die ontvangkant is, lees Die Gevare van Rebasing (The Perils of Rebasing).

'n Voorbereide lêer onttrek (Unstaging a Staged File)

Die volgende twee afdelings demonstreer hoe om met veranderings in jou voorbereidingsarea (staging area) en werkgids (working directory) te werk. Die lekker deel is dat die opdrag wat jy gebruik om die toestand van daardie twee areas te bepaal, jou ook herinner hoe om veranderings aan hulle ongedaan te maak. Byvoorbeeld, sê nou jy het twee lêers verander en wil hulle as twee aparte veranderings vaslê (commit), maar jy tik per ongeluk git add * en berei albei voor (stage). Hoe kan jy een van die twee onttrek (unstage)? Die git status opdrag herinner jou:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README
    modified:   CONTRIBUTING.md

Net onder die “Changes to be committed” teks, sê dit gebruik git reset HEAD <file>…​ om te onttrek (unstage). So, kom ons gebruik daardie raad om die CONTRIBUTING.md lêer te onttrek (unstage):

$ git reset HEAD CONTRIBUTING.md
Unstaged changes after reset:
M	CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Die opdrag is 'n bietjie vreemd, maar dit werk. Die CONTRIBUTING.md lêer is gewysig maar weereens onttrek (unstaged).

Note

Dit is waar dat git reset 'n gevaarlike opdrag kan wees, veral as jy die --hard vlag (flag) verskaf. In die scenario wat hierbo beskryf is, word die lêer in jou werkgids (working directory) egter nie geraak nie, so dit is relatief veilig.

Vir eers is hierdie tower-opdrag al wat jy hoef te weet oor die git reset opdrag. Ons sal in baie meer detail ingaan oor wat reset doen en hoe om dit te bemeester om werklik interessante dinge te doen in Reset Ontmystifiseer (Reset Demystified).

'n Gewysigde lêer ongewysig maak (Unmodifying a Modified File)

Wat as jy besef dat jy nie jou veranderings aan die CONTRIBUTING.md lêer wil behou nie? Hoe kan jy dit maklik ongewysig maak — dit terugrol (revert) na hoe dit gelyk het toe jy laas vasgelê (committed) het (of oorspronklik gekloon (cloned) het, of hoe jy dit ook al in jou werkgids (working directory) gekry het)? Gelukkig vertel git status jou ook hoe om dit te doen. In die laaste voorbeeld se afvoer, lyk die onttrekte area (unstaged area) soos volg:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Dit vertel jou redelik eksplisiet hoe om die veranderings wat jy gemaak het weg te gooi (discard). Kom ons doen wat dit sê:

$ git checkout -- CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Jy kan sien dat die veranderings teruggerol (reverted) is.

Important

Dit is belangrik om te verstaan dat git checkout — <file> 'n gevaarlike opdrag is. Enige plaaslike veranderings wat jy aan daardie lêer gemaak het, is weg — Git het net daardie lêer vervang met die laaste voorbereide (staged) of vasgelegde (committed) weergawe. Moet nooit hierdie opdrag gebruik nie, tensy jy absoluut seker is dat jy nie daardie ongestoorde (unsaved) plaaslike veranderings wil hê nie.

As jy die veranderings wat jy aan daardie lêer gemaak het, wil behou, maar dit vir eers uit die pad wil kry, sal ons oor wegbêre (stashing) en vertakking (branching) in Git Branching praat; dit is oor die algemeen beter maniere om dinge te hanteer.

Onthou, enigiets wat in Git vasgelê (committed) is, kan byna altyd herstel word. Selfs vasleggings (commits) wat op takke (branches) was wat uitgevee is, of vasleggings (commits) wat oorskryf (overwritten) is met 'n --amend vaslegging (commit), kan herstel word (sien Dataherwinning vir dataherwinning). Enigiets wat jy egter verloor wat nooit vasgelê (committed) is nie, sal waarskynlik nooit weer gesien word nie.

Dinge ongedaan maak met git restore

Git weergawe 2.23.0 het 'n nuwe opdrag bekendgestel: git restore. Dit is basies 'n alternatief vir git reset wat ons pas gedek het. Vanaf Git weergawe 2.23.0 en verder sal Git git restore in plaas van git reset vir baie ongedaan-maak operasies gebruik.

Kom ons gaan terug op ons voetspore en maak dinge met git restore ongedaan in plaas van git reset.

'n Voorbereide lêer onttrek met git restore (Unstaging a Staged File with git restore)

Die volgende twee afdelings demonstreer hoe om met veranderings in jou voorbereidingsarea (staging area) en werkgids (working directory) met git restore te werk. Die lekker deel is dat die opdrag wat jy gebruik om die toestand van daardie twee areas te bepaal, jou ook herinner hoe om veranderings aan hulle ongedaan te maak. Byvoorbeeld, sê nou jy het twee lêers verander en wil hulle as twee aparte veranderings vaslê (commit), maar jy tik per ongeluk git add * en berei albei voor (stage). Hoe kan jy een van die twee onttrek (unstage)? Die git status opdrag herinner jou:

$ git add *
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   CONTRIBUTING.md
	renamed:    README.md -> README

Net onder die “Changes to be committed” teks, sê dit gebruik git restore --staged <file>…​ om te onttrek (unstage). So, kom ons gebruik daardie raad om die CONTRIBUTING.md lêer te onttrek (unstage):

$ git restore --staged CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   CONTRIBUTING.md

Die CONTRIBUTING.md lêer is gewysig maar weereens onttrek (unstaged).

'n Gewysigde lêer ongewysig maak met git restore (Unmodifying a Modified File with git restore)

Wat as jy besef dat jy nie jou veranderings aan die CONTRIBUTING.md lêer wil behou nie? Hoe kan jy dit maklik ongewysig maak — dit terugrol (revert) na hoe dit gelyk het toe jy laas vasgelê (committed) het (of oorspronklik gekloon (cloned) het, of hoe jy dit ook al in jou werkgids (working directory) gekry het)? Gelukkig vertel git status jou ook hoe om dit te doen. In die laaste voorbeeld se afvoer, lyk die onttrekte area (unstaged area) soos volg:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   CONTRIBUTING.md

Dit vertel jou redelik eksplisiet hoe om die veranderings wat jy gemaak het weg te gooi (discard). Kom ons doen wat dit sê:

$ git restore CONTRIBUTING.md
$ git status
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	renamed:    README.md -> README
Important

Dit is belangrik om te verstaan dat git restore <file> 'n gevaarlike opdrag is. Enige plaaslike veranderings wat jy aan daardie lêer gemaak het, is weg — Git het net daardie lêer vervang met die laaste voorbereide (staged) of vasgelegde (committed) weergawe. Moet nooit hierdie opdrag gebruik nie, tensy jy absoluut seker is dat jy nie daardie ongestoorde (unsaved) plaaslike veranderings wil hê nie.