Git
Chapters ▾ 2nd Edition

2.4 Mga Pangunahing Kaalaman sa Git - Pag-Undo ng mga Bagay

Pag-Undo ng mga Bagay

Sa anumang yugto, baka gusto mong i-undo ang isang bagay. Dito, susuriin natin ang iilang mga pangunahing mga kasangkapan para sa pag-undo ng mga pagbabago na ginawa mo. Mag-ingat ka, dahil hindi mo laging i-undo ang ilan sa mga undo na ito. Ito ay isa sa ilang mga lugar sa Git na kung saan maaari kang mawalan ng trabaho kung mali ang pagkagawa mo nito.

Isa sa mga karaniwang mga undo ay magaganap kapag gumawa ka ng commit na masyadong maaga at marahil kalimutan na magdagdag ng ilang mga file, o ikaw ay gumulo sa iyong commit na mensahe. Kung nais mong gawing muli ang commit na iyon, gawin ang karagdagang mga pagbabago na nakalimutan mo, i-yugto sila, at commit uli gamit ang --amend option:

$ git commit --amend

Ang utos na ito ay kumukuha ng iyong staging na lugar at ginagamit ito para sa commit. Kung wala kang pagbabago mula noong iyong huling commit (halimbawa, agad mong pinatakbo ang utos na ito pagkatapos ng iyong nakaraan na commit), pagkatapos ang iyong snapshot ay magiging eksaktong magkatulad, at lahat ng iyong babaguhin ay ang iyong commit na mensahe.

Ang parehong commit-mensahe na editor ay nag-aapoy, ngunit naglalaman na ito ng mensahe sa nakaraan mong commit. Maaari mong i-edit ang mensahe na katulad palagi, ngunit ito ay nag-overwrite ng iyong huling commit.

Bilang isang halimbawa, kung mag-commit ka at pagkatapos ay mapagtanto mong nakalimutan ang yugto sa mga pagbabago sa isang file na nais mong idagdag sa commit na ito, maaari mong gawin ang isang bagay na tulad nito:

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

Nagtatapos ka ng may isang solong commit — ang pangalawang commit ay pumapalit sa mga resulta ng una.

Mahalagang unawaan na kapag binabago mo ang iyong huling commit, hindi ka masyadong nag-aayos nito bilang kapalit na ganap na may bago, pinagbuti na commit na nagpapatuloy sa lumang commit na wala sa daan at inilalagay ang bagong commit sa lugar na ito. Mabisa, ito ay kung ang dating commit ay hindi nangyari, at ito ay hindi nagpapakita ng iyong kasaysayan ng repositoryo.

Ang malinaw na halaga sa pagbabago ng mga commit ay gumawa ng mga menor na mga pagpapabuti sa iyong huling commit, wala nang kalat sa iyong kasaysayan ng repositoryo na may commit na mga mensahe ng form, “Oops, forgot to add a file” o “Darn, fixing a typo in last commit”.

Hindi pagyuyugto ng isang Yugtong File

Ang susunod na dalawang seksyon ay ipinapakita kung papaano magtrabaho sa iyong yugtong lugar at tinatrabahong direktoryo na mga pagbabago. Ang ganda ng bahagi ay ang utos upang matukoy ang kalagayan ng dalawang lugar na iyon na nagpapaalala rin sa iyo kung papaano magbabago sa kanila. Halimbawa, sabihin natin na ang nabago na dalawang file at nais na gawin ang commit na sila bilang dalawang hiwalay na pagbabago, ngunit hindi mo sinasadya ang pag-type ng git add * at yugto silang pareho. Paano ka mag-unstage sa isa sa dalawa? Ang git status na utos na nagpapaalala sa iyo:

$ 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

Sa baba ng “Changes to be committed” na teksto, sinasabi nito ang paggamit git reset HEAD <file>... sa unstage. Kaya, gamitin natin ang payo na iyon upang i-unstage ang CONTRIBUTING.md na file:

$ 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

Ang utos ay medyo kakaiba, ngunit ito ay gumagana. Ang CONTRIBUTING.md na file ay binago ngunit muling na unstaged.

Totoo iyon na ang git reset ay maaaring isang mapanganib na utos, lalo na kung ibinigay mo ang --hard na flag. Gayunpaman, sa senaryo na inilarawan sa itaas, ang file sa iyong tinatrabahong direktoryo ay hindi hinawakan, kaya medyo ligtas.

Sa ngayon ito ay salamangka ng pagsang-ayon ay ang lahat na iyong kailangan na malaman tungkol sa git reset na utos. Puntahan natin ang mas detalye na tungkol sa ano ang reset na gagawin at kung papaano ito i-master upang gawin talaga ang kawili-wiling mga bagay sa Ang Reset Demystified.

Ang Pagbalik sa Pagbago ng Binagong File

Paano kung napagtanto mo na ayaw mong panatilihin ang iyong pagbabago sa CONTRIBUTING.md na file? Paano mo napadali ang pagbalik sa pagbago nito — ibalik ito pabalik sa kung ano ang mukha nito bago ka huling na-commit (o nagsimula na naka-clone, o gayunpaman nakuha mo ito sa iyong tinatrabaho na direktoryo)? Sa kabutihang palad, git status nagsasabi sa iyo kung paano gawin iyon, din. Sa huling halimbawa ng output, ang unstaged na lugar ay mukhang ganito:

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

Ito ay nagsasabi sa iyo ng medyo malinaw kung papaano itiwalag ang mga pagbabago na iyong ginawa. Gawin natin ang sinasabi nito:

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

    renamed:    README.md -> README

Nakikita mo na ang mga pagbabago ay naibalik na.

Ito ay mahalagang maunawaan na ang git checkout -- <file> ay isang delikadong utos. Anumang mga pagbabago na iyong ginawa sa file ay mawawala — Ang Git ay naka-kopya ng ibang file sa ganito. Huwag kailanman gumamit sa utos maliban kung ikaw ay talagang alam na hindi mo gusto ang file.

Kung nais mong panatilihin ang pagbabago na nagawa mo sa file na iyon ngunit kailangan mo pa rin na lumabas daanan sa ngayon, pupunta tayo sa stashing at branching sa Pag-branch ng Git; ang mga ito ay pangkalahatang mas mahusay na paraan upang pumunta.

Tandaan, kahit ano ang na-commit sa Git ay maaaring halos palaging mababawi. Kahit na ang mga commit na nasa branch na natanggal na o mga commit ay napalitan na ng --amend ang commit ay pwedeng mababawi (tingnan Pagbalik ng Datos para sa pagbawi ng datos). Gayunpaman, anumang bagay ang iyong mawala na hindi pa na-commit ay malamang hindi na makikita muli.

scroll-to-top