Let's return to the Asteroids repository from the previous lesson.
Do you remember the bug you saw, where you could shoot without a delay?
You now have the knowledge you need to fix that bug and commit your fix.
First, I'll do a git log.
Now, I'll scroll down to the commit where you found the bug had been introduced.
You may recall that it was this commit.
To double check, I'll use diff to compare it to the previous one.
Sure enough, this commit removed the line, this.delayBeforeBullet = 10.
I want to readd this line, so I'll go ahead and copy it.
And I can see that it should be added inside the if statement,
this.delayBeforeBullet is less than or equal zero.
I'll open game.js in Sublime.
Search for delayBeforeBullet.
And hit Find until I find the appropriate if statement.
Here it is, so I'll insert the line.
Now I'm ready to add the file to the staging area, and then commit it.
First I'll use git status.
And I can see that game.js has been modified, and that the changes
are not staged yet, which means that they are not in the staging area.
Right now, I remember exactly what changes I've made to game.js since I
made them just a minute ago.
But often, I'll find myself making changes, taking a break, and
then coming back and forgetting what changes I've made.
So I'm going to show you how to use git diff to see the exact changes that
you've introduced since committing.
To make the illustration more clear, I'm also going to introduce a change to
index.html that I don't want to commit yet.
I'll just collapse this line onto the previous line.
Let's think about what the working directory, staging area and
repository look like right now.
The repository contains several commits.
And each commit contains several files.
I'll focus on the most recent commit in the files game.js and index.html.
The staging area is a copy of the most recent commit until I add changes to it,
so it has those same files.
Finally, the working directory also has the same files in it, but I've made
some updates to game.js and index.html, which I'll represent using these stars.
You know that you can use git diff to compare two commits by
entering their commit ID's.
But the staging area and
the working directory are not commits, so they don't have ID's.
However, it's very common for Git users to want to compare the working
directory to the staging area, so git diff with no arguments will do that.
This will show any changes you've made that you haven't added to
the staging area yet.
So I'll go ahead and
run git diff with no arguments, and I can see the two changes I just introduced.
Here's the change to game.js, where I re-added the delayBeforeBullet.
And here's the change to index.html, where I combined two lines into one.
Now, I'll add game.js to the staging area and run git diff again.
This time, I only see the changes to index.html,
since game.js is the same in the staging area and working directory now.
Now, the staging area contains the updated version of game.js, but
not of index.html.
That's why, when I used git diff to compare these two,
I only saw the changes to index.html.
Now, you might also want to view the difference between the staging area and
the most recent commit.
I like to do this right before I commit, to double check that the files I've
added are really what I want to put in the commit.
The command for this is git diff --staged.
If I run this command now, I should see the changes to game.js, but
not index.html, since index.html is still the same.
Sure enough, git diff --staged shows only the change to game.js.
This is exactly what I want to commit.
So I'll go ahead and type git commit.
And I'll use the message: Add delay back to bullets.
Now, I'll run git diff again and
I'll still see the changes to index.html, since I haven't committed those.
If I run git diff --staged though,
I see nothing, since I did just commit everything in the staging area.
Finally, I don't actually want these changes to index.html anymore.
To get rid of them, I'll run git reset --hard.
Which discards any changes in either the working directory or the staging area.
But be very careful if you ever run this.
Most actions in git are reversible,
since you can always restore previous commits.
But you've never committed the changes in your working directory or
staging area.
So if you run this command, you can't get those changes back.
In this case, I had just run both git diff and git diff -staged.
So I know exactly what changes are in the working directory and
staging area, and I'm sure I don't want them anymore.
Now I'll run git diff again.
And there are no changes.
What two versions of your files does each form of git diff compare?
For each form of git diff,
fill in the two versions that compares in these boxes.
Each box should contain either working directory, staging area, commit one or
commit two.
Note that commit one is the most recent commit in this repository