I always love Git documentation that includes warnings about destructive commands (like this one) because there’s no way to get this code back (aka a data loss scenario), unless the code happens to be in your favorite editor’s buffer or you still secretly use Ctrl+C Ctrl+V for emergencies – DONT JUDGE ME PEOPLE! =p For example, from unmodifying a modified file
It’s important to understand that
git checkout -- [file]is a dangerous command. Any changes you made to that file are gone – you just copied another file over it. Don’t ever use this command unless you absolutely know that you don’t want the file.
I think to myself, “Um, Git, you know the code I’m writing… there’s a reason I never want to speak of this code again!!” It seems Git was designed for people who never have to StackOverflow with cut and paste attempts just to get something to compile and yet forgot to try on a throwaway branch first. It’s once I get it to compile I want to start over as if to convey in my logs, “yep I knew what I was doing all along…”
tl;dr – Today’s Git tip of the day is when you’re feeling, “um, yeah, let’s pretend that never happened.”
Undo changes in specific file in working directory using Team Explorer
In Visual Studio, let’s add a few lines of code in our Program.cs project and hit save. You’ll immediately see Team Explorer telling you that you have unstaged changes in your working directory. Note that I say “unstaged changes” and not “uncommited changes.” Remember, even though Team Explorer lets you jump over staging, there’s still a “middle layer” as seen in the past couple of tips.
Right-click Program.cs and click Undo.
Now you’ll be prompted “are you sure” because like the Git documentation says, you won’t be able to get these changes back.
Now we’re back to before we made any unstaged and/or uncommitted modifications. Even VS seems to know to pop these changes from its clipboard ring. Wow, I feel for whoever had to test those scenarios!
Undo changes in specific file in working directory using Command Line
I believe this is the command line equivalent of running git checkout — <filename> although I’m not sure what the actual underlying plumbing Team Explorer is doing.
If we want to rinse and repeat from the command line,
First, make some edits in Visual Studio and hit save. We can confirm these changes by doing a git status
Next we’ll run the dangerous (aka data loss) command git checkout — <filename>
Although Git is like “Meh”, Visual Studio grabs your attention immediately with the old-faithful FILES HAVE CHANGED FILE HAVE CHANGE OMG FILES HAVE CHANGED WHAT DO WE DO?!?! dialog.
Since we made these changes from the command line, Visual Studio needs to know what to do with the current text buffer. In this case, we purposefully made these changes, so we want to say Yes to All.
And we’ll see that we’re back to our baseline code and no more changes being tracked in Team Explorer.
and Git from the command prompt confirms it.
Aside: What if you had said “No” or “No to All”?
Well, I guess Git won’t be aware of what state your file really is in. If you try to git add or git commit the untracked changes in Program.cs, Git will ignore you. Literally. Git says “nothing to commit, working tree clean.” Team Explorer will also do the same by not giving you any options. But as soon as you hit Save in VS (even if the file is already saved) or even type another character in the text buffer, Git picks back up on the changes.
I guess the take-home message is to hit Yes to All. If you have a scenario where you’d want to say No to All in such a situation (perhaps making this “less dangerous” although there are many, many better ways), please let me know!
Sara Ford's Blog 