Rolling back a commit in git vs hg

Basically both require one command to reset the local tree, another to actually change the file(s) back.

If I mess up and commit something by mistake (or unwisely on purpose) in one of my Mercurial repositories and haven’t done a push yet, I do this:

hg rollback

This resets the repo to the last commit, but does not revert any files to their previous state.

hg revert [filename]

Will revert named files (“hg revert goodscript.pl”) to their previous state, reversing any changes made.

Use “hg log|more” (hg log will not stop to page) and “hg status” to check current state of repo.

For git? Use git reset. Here’s the sequence (taken from this post on Stack):

git reset --soft HEAD~1

Resets the pointer to the previous commit.

git reset --hard

Reverts files changed in the now rolled back commit to what they were before.

If you haven’t yet done a commit, but have done an add, hitting “git reset” will roll back the add.

This is different from situations in which you want to roll back a change to a file, like an edit or a wholesale delete. In such cases you’ll use the git checkout command.

Always use “git log” and “git status” to show previous commits (including commit IDs) and current repo state, especially when sharing a repository among multiple developers or where you have multiple copies of the same repo.

This entry was posted in Development on by .

About phil

My name is Phil Lembo. In my day job I’m an enterprise IT architect for a leading distribution and services company. The rest of my time I try to maintain a semi-normal family life in the suburbs of Raleigh, NC. E-mail me at philipATlembobrothersDOTcom. The opinions expressed here are entirely my own and not those of my employers, past, present or future (except where I quote others, who will need to accept responsibility for their own rants).