7.7 Mga Git na Kasangkapan - Ang Reset Demystified

Isang mas madaling paraan para isipin ang tungkol sa reset at checkout ay sa pamamagitan ng mental frame sa Git sa pagiging tagapamahala ng nilalaman sa tatlong magkaibang mga tree. Sa pamamagitan ng “tree” dito, talagang ibig sabihin nito ay “collection of files”, hindi particular na kaayusan ng datos. (Mayroong ilang mga kaso na kung saan ang index ay hindi eksaktong kumikilos tulad ng isang tree, para sa aming mga gamit ito ay mas madali para isipin ang tungkol nito sa ganitong paraan para sa ngayon.)

Ang Git bilang isang sistemang namamahala at humahawak sa tatlong mga tree sa kanyang normal na operasyon:

Ang pangunahing layunin sa Git ay ang pagtatala ng mga snapshot sa iyong proyekto sa sunod-sunod na mas mabuting estado, sa pamamagitan ng pagmamanipula ng mga tatlong mga tree.

Isalarawan natin ang prosesong ito: sabihin mong pumasok ka sa isang bagong direktoryo na may isang solong file sa loob. Tatawagan natin itong v1 sa file, at ipapakita natin ito sa asul. Ngayon nagpatakbo kami ng git init, na kung saan ikaw ay lumikha ng isang Git na repositoryo na may isang HEAD na reperensiya na kung saan ang mga puntos sa isang hindi pa isinisilang na branch (ang master ay hindi umiiral pa).

Sa puntong ito, Tanging ang Tinatrabahong Direktoryo na tree ay merong anumang nilalaman.

Ngayon gusto nating i-commit ang file na ito, kaya gumamit kami ng git add upang kunin ang nilalaman ng Tinatrabahong Direktoryo at kopyahin ito sa Index.

Pagkatapos ay pinatakbo natin ang git commit, na kumukuha ng mga nilalaman sa Index at sine-save ito bilang isang permanenteng snapshot, lumilikha ng isang commit na bagay na kung saan ay nagtuturo sa snapshot na iyon, at i-update ang master upang ituro ang commit na iyon.

Kung magpatakbo ng git status, hindi kami makakita ng mga pagbabago, dahil lahat ng tatlong mga tree ay pareho lang.

Ngayon gusto nating gumawa ng isang pagbabago sa file na iyon at i-commit ito. Kami ay dumadaan sa parehong proseso; una ay binago natin ang file sa aming tinatrabahong direktoryo. Tawagin natin itong v2 sa file, at ipahiwatig ito sa pula.

Kung patakbuhin natin ang git status ngayon na, makikita natin ang file sa pula bilang “Pagbabago ay hindi naka-stage para commit,” dahil ang entry na ito ay naiiba ang Index at ang Tinatrabahong Direktoryo. Susunod pinatakbo natin ang git add dito upang i-stage ito sa ating Index.

Sa puntong ito, kung ipatakbo natin ang git status, makikita natin ang file sa berde sa ilalim ng “Pagbabago na i-commit” dahil ang Index at HEAD na pagkaiba — yan ay, ang aming iminungkahi sa susunod na commit na ngayon ay naiiba mula sa ating huling commit. Sa wakas, kami ay nagpatakbo ng git commit upang makumpleto ang commit.

Ngayon ang git status ay magbibigay sa amin nang walang output, dahil lahat ng tatlong mga tree ay pareho muli.

Paglipat ng mga branch o pag-clone ay dumadaan sa isang katulad na proseso. Kapag ikaw ay nag-checkout sa isang branch, ito ay nagbabago ng HEAD upang ituro sa bagong branch na ref, nagpapalaganap na iyong Index na gamit ang snapshot sa commit na iyon, pagkatapos ay kumukopya sa mga nilalaman sa Index sa iyong Tinatrabahong Direktoryo.

Ang reset na utos ay mas makakatulong kapag tiningnan sa kontekstong ito.

Para sa mga layunin sa mga halimbawang ito, sabihin natin na binago natin ang file.txt muli at naka-commit ito sa ikatlong pagkakataon. Kaya ngayon ang aming kasaysayan ay katulad nito:

Maglakad na tayo ngayon sa pamamagitan ng eksaktong kung ano ang reset ay kapag tinawag mo ito. Ito ay direktang nagmanipula ang tatlong mga tree sa isang simple at mahuhulaan na paraan. Ginagawa ito sa tatlong pangunahing mga operasyon.

That covers the behavior of reset in its basic form, but you can also provide it with a path to act upon. If you specify a path, reset will skip step 1, and limit the remainder of its actions to a specific file or set of files. This actually sort of makes sense — HEAD is just a pointer, and you can’t point to part of one commit and part of another. But the Index and Working directory can be partially updated, so reset proceeds with steps 2 and 3.

So, assume we run git reset file.txt. This form (since you did not specify a commit SHA-1 or branch, and you didn’t specify --soft or --hard) is shorthand for git reset --mixed HEAD file.txt, which will:

So it essentially just copies file.txt from HEAD to the Index.

This has the practical effect of unstaging the file. If we look at the diagram for that command and think about what git add does, they are exact opposites.

This is why the output of the git status command suggests that you run this to unstage a file. (See Hindi pagyuyugto ng isang Yugtong File for more on this.)

We could just as easily not let Git assume we meant “pull the data from HEAD” by specifying a specific commit to pull that file version from. We would just run something like git reset eb43bf file.txt.

This effectively does the same thing as if we had reverted the content of the file to v1 in the Working Directory, ran git add on it, then reverted it back to v3 again (without actually going through all those steps). If we run git commit now, it will record a change that reverts that file back to v1, even though we never actually had it in our Working Directory again.

It’s also interesting to note that like git add, the reset command will accept a --patch option to unstage content on a hunk-by-hunk basis. So you can selectively unstage or revert content.

Let’s look at how to do something interesting with this newfound power — squashing commits.

Say you have a series of commits with messages like “oops.”, “WIP” and “forgot this file”. You can use reset to quickly and easily squash them into a single commit that makes you look really smart. (Pag-squash ng mga Commit shows another way to do this, but in this example it’s simpler to use reset.)

Let’s say you have a project where the first commit has one file, the second commit added a new file and changed the first, and the third commit changed the first file again. The second commit was a work in progress and you want to squash it down.

You can run git reset --soft HEAD~2 to move the HEAD branch back to an older commit (the most recent commit you want to keep):

And then simply run git commit again:

Now you can see that your reachable history, the history you would push, now looks like you had one commit with file-a.txt v1, then a second that both modified file-a.txt to v3 and added file-b.txt. The commit with the v2 version of the file is no longer in the history.

Finally, you may wonder what the difference between checkout and reset is. Like reset, checkout manipulates the three trees, and it is a bit different depending on whether you give the command a file path or not.

Hopefully now you understand and feel more comfortable with the reset command, but are probably still a little confused about how exactly it differs from checkout and could not possibly remember all the rules of the different invocations.

Here’s a cheat-sheet for which commands affect which trees. The “HEAD” column reads “REF” if that command moves the reference (branch) that HEAD points to, and “HEAD” if it moves HEAD itself. Pay especial attention to the WD Safe? column — if it says NO, take a second to think before running that command.