Objective: In this repository, you will learn how to use the power of Git to undo any changes you've made.
This will be in the form of a scavenger hunt. Better than knowing what to type is knowing where to look for what to type.
- In the top-right corner of this repository, you should see a Fork button. Click that.
- At the top you should now see yourUserName/rollback-scavenger-hunt. If you don't, try step 1 again.
- Click the green Clone or download button. Make sure it says SSH (not HTTPS), then click the clipboard icon to copy.
- In your IDE command line, at
~/github-learning/
, typegit clone URL
, whereURL
is the long link you just copied. You can just paste it in there. Make sure it saysgit clone [email protected]:YOURUSERNAME/rollback-scavenger-hunt.git
before you press enter. - Go ahead and
cd
into your newly cloned repo! - Open
rollback.md
and use that file for all of the following directions. It is extremely important that you read and follow directions VERY carefully!
Go ahead and make some changes to rollback.md
. Whatever you want. It doesn't matter. Add some text, delete some, change some, etc.
Great! Now you've made some edits, but let's say you want to undo that. Here's your hint: type git status
. Notice that git
is giving you two hints:
On branch master
Changes not staged for commit:
(use "%%%%%%%%%%%%" to update what will be committed)
(use "%%%%%%%%%%%%" to discard changes in working directory)
modified: rollback.md
Yes, the commands have been replaced with %%%%%%%%%%%%
. You need to type the command that will discard your changes. NOTE: you do NOT need to type the ...
or the < >
symbols.
Now you know how to undo edits!
This is one of the most frequently used "rollback" commands. Suppose you're working on a repo with someone else, and you accidentally started editing a file that you shouldn't have (because you know you're going to get a merge conflict, and you'd rather avoid it altogether than have to deal with it). Instead of doing edit > undo
a whole bunch of times, using this command will reset that file (or multiple files) back to the last commit to ensure it's exactly how it was before you started editing.
Go ahead and make some changes to rollback.md
again, but this time go ahead and add
the file to the stage. Now rollback.md
is green, yah? Well the only way you would know that is if you type git status
. Since you did, notice what it says above the green filename. Go ahead and type that.
Doing git status
again should bring the file back to red. Hooray! We unstaged it.
Let's say you edit two files, and you accidentally did git add .
(which adds both files to the stage), but you only meant to add one of the files (the other one is still broken). You would want to remove the broken file from the stage with this command.
Where we just left off, rollback.md
is red, which means it has changes but isn't on the stage. Go ahead and add
it to the stage and commit
it.
Whoops! Let's say we didn't mean to take that snapshot. How do we undo it? Unfortunately, git status
won't help you this time. You'll have to rely on your next best friend: Google.
Do a search for git undo commit
. One of the first result points to Stackoverflow, a great coding forum where people ask and answer questions. The best part about is that common questions get "upvoted", and so do the best answers. Notice how many times this question has been upvoted: over 20,000 times. If you scroll down a little bit, you'll see answers. (NOTE: the link MIGHT take you to Page 2, highlighted in orange. If so, please click on Page 1). Also notice how many times the "best" answer has been upvoted: almost 22,000 times (you'll see a little ✅).
While the most upvoted answer is usually the first place to look, it never hurts to look beyond it (just like looking at more than just the first search result when using Google). In this case, the second-most upvoted answer is what we want (the one with over 10,000 votes). It has a pretty good explanation of how to do exactly what we want.
Read the first couple of paragraphs, but pay careful attention to this part (note: index means staging area)
For the lightest touch, you can even undo your commit but leave your files and your index
Type the command that will do that.
Yay! You just un-commited. Using git status
shows us the green file which means we're right back to where we were before we made the commit.
If you want to leave the files in the staging area, that means you don't need to make any edits. So this only really applies to changing your commit message. All it will do is undo typing git commit -m "blah blah blah"
.
Where we just left off, we "un-commited", so our file is still green which means it still has the edits and it's on the stage, ready to be committed.
Let's go ahead and commit it again, then we're going to destroy the commit. Look at the same post on Stackoverflow for this:
You want to undo the commit but keep your changes for a bit of editing before you do a better commit.
Go ahead and do that.
Sweet! You just undid both the commit
and the add
, so a git status
should show you the file in red.
This would probably be helpful if you spotted a small typo right after you commit, or wanted to include something else in this snapshot, so you need to undo the commit and reset the staging area.
Where we just left off, we "un-commited" and "un-added", so a git status
shows that our file is red which means it still has the edits but it's not on the stage.
Let's go ahead and add and commit it again. We're about to destroy the commit
, the add
, and the edits (taking us all the way back to our last commit). Looking back at the same post on Stackoverflow, do you see how you can completely destroy your last commit?
You want to nuke commit C and never see it again.
Nuke it.
This is a very dangerous command, so use it sparingly. It's much safer to rollback to a previous commit.
At this point, you've already seen git revert
in an earlier lesson. But if you want to, you can search for: git rollback to previous commit and learn even more. The point is to try things, mess them up, and make sure you read for understanding. You may get merge conflicts with yourself. Remember, git status
is your best friend. You got this. 👍