Bummer! This is just a preview. You need to be signed in with a Basic account to view the entire video.
Viewing Changes to a File5:45 with Jay McGavren
You've updated a file, but you've forgotten the specific changes you made. Because Git knows what the previous version looked like, it can show you the differences.
- Git can show you exactly how your files have changed over time.
- We've shown you the
git log -poption, which shows the changes made within each commit.
- But we can also use Git to see changes in our files before we commit them.
- Suppose we added a heading to our site's main page. Open up
medals.html, and at the top add a level 1 heading:
<h1>Welcome to our store!</h1>.
- Also add a descriptive paragraph:
<p>Please choose a section below.</p>
- Once the file is saved, we can use the
git diffcommand to view those changes.
treehouse:~/workspace/medals$ git diff diff --git a/medals.html b/medals.html index 5f5fbe7..08982c3 100644 --- a/medals.html +++ b/medals.html @@ -1,3 +1,6 @@ +<h1>Welcome to our store!</h1> +<p>Please choose a section below.</p>
- Git will compare the current contents of your files to what's in the staging area, and show you what's changed. If nothing is staged, then it will compare your files with the contents of your previous commit.
- New lines will show with a
+sign in front of them.
- Removed lines will show with a
-sign in front of them.
- And changed lines will show with a
-sign in front of the old version, and a
+sign in front of the new version.
- Now let's stage the file:
git add medals.html.
- Let's try running
git diffagain. This time it exits without showing any output.
- That's because
git diffcompares the contents of your files against the contents of the staging area. If your changes are already staged, then there's no difference to show.
- But there's a command line option that will show you staged changes if you specify it:
git diff --staged. With the
git diffwill compare your staged changes against the previous commit.
Find a Workspace on Treehouse that you've been working in for a while, and turn it into a Git repo. (Or install Git to your computer and convert your favorite project directory to a repo.) You can store HTML files for a website, code files for a program, or even plain text files. If you need a project idea, try filling a directory with text files, where each file is a recipe for a cookbook.
- In the main project directory, initialize a new Git repo.
- Stage some (or all) of the project files, whatever will make a sensible first commit.
- Make your commit. Be sure to use a commit message that completes the sentence "This commit will..."
- Keep staging and committing until all your project files are committed.
- As you keep working on your project files, commit all your changes to the repo.
Another great thing about storing all the prior versions of your files is that
Git can show you exactly how your files have changed.
We've shown you the git log -p option,
which shows the changes made within each commit.
But we can also use Git to see the changes in our files before we command them.
Suppose we added a heading to our site's main page.
I've opened up medals.html, and here at the top I'll add a level one heading,
h1, Welcome to our store.
I'll also add a descriptive paragraph down here.
Paragraph, Please chose a section below.
Let me save that and then click back in the console area.
Now, suppose I got called away for a meeting and
I had to leave my computer for a while.
Now I'm back and I'm ready to commit my changes, but
I can't remember exactly what I've changed.
We can use the git diff command to view those changes.
Diff stands for difference, as in, show me the differences in these files.
Git will compare the current contents of your files to what's in the staging area
and show you what's changed.
If nothing gets staged,
then it will compare your files with the contents of your previous commit.
New lines show up with a plus sign in front of them.
Removed lines will show up with a minus sign in front of them.
And changed lines will show with a minus sign in front of the old version, and
a plus sign in front of the new version.
Diffs are one of my favorites features of Git.
When you're working on a large software project,
it's easy to lose track of what's changed and where.
Diffs can immediately find the changes for
you, even if they're buried in a large file.
This works regardless of whether you made the change, or another developer did.
So looking at this diff output,
I can see that I've added a heading to the main page.
Now I know what I need to write in my commit message.
Let's stage the file.
Git add medals.html.
Now let's try running git diff again.
This time it exits without showing any output.
That's because git diff compares the contents of your files against
the contents of the staging area.
If your changes are already staged, then there's no difference to show.
But there's a command line option that will show you staged changes if you
specify it, git diff --staged.
With the staged option,
get diff will compare your staged changes against the previous commit.
Now let's commit our changes.
Git commit -m Add heading.
With all our changes committed, if we run git diff again, it will show
no output because there is no difference between our current file contents and
the staging area.
There's also no difference between the staging area and the previous commit,
so git diff --staged doesn't show any output either.
There's a situation that can come up that can be a little confusing,
until you understand how the git add command works.
Suppose we made another change to metals.html.
We'll add a paragraph to the page, Thank you for shopping with us.
We save that, click back in our console and add the modified file to staging.
Git add metals.html.
Now let's run git status.
And the file will appear in the changes to be committed section.
But let's suppose we forgot to add some punctuation on our sentence and
went back to add it.
Thank you for shopping with us!
Save that, and let's click back in the console and run git status again.
This time, we see the medals.html file as both staged and unstaged.
This is because git stages the file as it existed at the time we ran git add.
You can see this if we run git diff --staged.
What's staged is the version of the paragraph with no punctuation.
If we run git diff without the double dash staged option,
it will compare our modified file with the staged file and
show us the difference, that is, the exclamation point.
We can update the staged version by running git add on the file again,
git add medals.html.
If we run git status again, we'll see that the changes not staged for
commit section is gone.
There's only a changes to be committed section, and
that section includes medals.html.
If we run git diff, there will be no output,
showing there's no difference between our modified file and the staging area.
And if we run git diff --staged,
it will show only the version of our paragraph that has punctuation.
Now we can safely commit our staged file, git commit -m Add thanks.
So remember, if you stage a file,
git staged is a snapshot of the file at the moment you staged it.
If you modify the file after that,
you'll need to run git add on it again to stage the latest changes.
In this stage, we showed you how to initialize a Git repository and
commit files to it.
Practicing your new skills is important to remembering them, so
be sure to check the teacher's notes on this video for some practice ideas.
We promised you that Git could also keep you from losing work.
In the next stage, you'll see commands that will restore accidentally deleted
files, bring back file contents from old commits, and more.
We'll see you in the next stage.
You need to sign up for Treehouse in order to download course files.Sign up