I've been sending weekly "Protip" emails about Git to the rest of engineering here at Slide for a while now, using the "Protips" as a means of introducing more interesting and complex features Git offers. Below is the third Protip written to date.



The concept of "revert" in Git versus Subversion is an interesting, albeit subtle, change, mostly in part due to the subtle differences between Git and Subversion's means of tracking commits. Just as with Subversion, you can only revert a committed change, unlike Subversion there is a 1-to-1 mapping of a "commit" to a "revert". The basic syntax of revert is quite easy: git revert 0xdeadbeef, and just like a regular commit, you will need to push your changes after you revert if you want others to receive the revert as well.

In the following example of a revert of a commit, I also use the "-s" argument on the command line to denote that I'm signing-off on this revert (i.e. I've properly reviewed it). 



xdev3% git revert -s c20054ea390046bd3a54693f2927192b2a7097c2


----------------[Vim]----------------


Revert "merge-to-release unhide 10000 coin habitat"





This reverts commit c20054ea390046bd3a54693f2927192b2a7097c2.





Signed-off-by: R. Tyler Ballance <tyler@slide.com>


# Please enter the commit message for your changes. Lines starting


# with '#' will be ignored, and an empty message aborts the commit.


# On branch wip-protips


# Changes to be committed:


#   (use "git reset HEAD <file>..." to unstage)


#


#   modified:   bt/apps/pet/data.py






+ python bt/qa/git/post-commit.py -m svn@slide.com


Sending a commit mail to svn@slide.com


Created commit a6e93b8: Revert "merge-to-release unhide 10000 coin habitat"


 1 files changed, 4 insertions(+), 3 deletions(-)



Reverting multiple commits


Since git revert will generate a new commit for you every time you revert a previous commit, reverting multiple commits is not as obvious (side note: I'm aware of the ability to squash commits, or --no-commit for git-revert(1), I dislike compressing revision history when I don't believe there shouldn't be compression). If you want to revert a specific merge from one branch into the other, you can revert the merge commit (provided one was generated when the changes were merged). Take the following example: 


commit 81a94bb976dfaaaae42ae2600b7e9e88645ebd81


Merge: 8134d17... d227dd8...


Author: R. Tyler Ballance <tyler@slide.com>


Date:   Thu Nov 20 10:15:16 2008 -0800





    Merge branch 'master' into wip-protips



I want to revert this merge since it refreshed my wip-protips branch from master, and brought in a lot changes tat have destablized my branch. In the case of reverting a merge commit, you need to specify -m and a number to denote where the mainline branch for Git to pivot off of is, -m 1 usually suffices. So the revert of the commit above will look something like this: 


git revert 81a94bb976dfaaaae42ae2600b7e9e88645ebd81 -m 1



Then my revert commit will be committed after I review the change in Vim: 


commit 8cae4924c4c05dadaaeccb3851cfc9ec1b8efd0f


Author: R. Tyler Ballance <tyler@slide.com>


Date:   Thu Nov 20 10:20:44 2008 -0800





    Revert "Merge branch 'master' into wip-protips"


    


    This reverts commit 81a94bb976dfaaaae42ae2600b7e9e88645ebd81.



Let's take the extreme case where I don't have a merge commit to pivot off of, or I have a particular set of bare revisions that I need to revert in one pass, you can start to tie Git subcommands together like git-rev-list(1) to accomplish this. This hypothetical situation might occur if some swath of changes have been applied to a team-master that need to be backed out. Without a merge commit to key off of, you have to revert the commits one by one, but that doesn't mean you have to revert each one by hand:
for r in `git rev-list master...master-fubar --since="8:00" --before="12:00" --no-merges`; do git revert --no-edit -s $r; done
In the above example, I can use git-rev-list(1) to give me a list of revisions that have occurred on "master-fubar" that have not occurred on "master" between the times of 8 a.m. and 12 p.m., excluding merge commits. Since git-rev-list(1) will return a list of commit hashes by default, I can loop through those commit hashes in chronological order and revert each one. The inner part of the loop signs-off on the revert (-s) and then tells git-revert(1) to auto-commit it without opening the commit message in Vim (--no-edit). What this then outputs is the following: 


xdev% for r in `git rev-list master...master-fubar  --since="8:00" --before="12:00" --no-merges`; do git revert --no-edit -s $r; done


Finished one revert.


Created commit b6810d7: Revert "a test, for you"


 1 files changed, 1 insertions(+), 1 deletions(-)


Finished one revert.


Created commit 83156bd: Revert "These are not the droids you are looking for


 1 files changed, 2 insertions(+), 0 deletions(-)


Finished one revert.


Created commit 782f328: Revert "commented out stuff"


 1 files changed, 0 insertions(+), 3 deletions(-)


Finished one revert.


Created commit 2b8d664: Revert "back on again"


 1 files changed, 1 insertions(+), 1 deletions(-)


xdev%



For specific usage of "git-revert" or "git-rev-list" refer to the git-revert(1) man page or the git-rev-list(1) man page


Did you know! Slide is hiring! Looking for talented engineers to write some good Python and/or JavaScript, feel free to contact me at tyler[at]slide