Staging & Committing Changes

Today, you’ll meet the “Staging Area” - one of Git’s very special and very useful concepts.

To begin with, let’s talk about the status that a file can have in version control.

On the most basic level, a file in your working directory can either be untracked or tracked. Untracked files haven’t been added to version control, yet. In most cases, these are simply new files. This means that, just because a file is in your project folder, it’s not automatically tracked by the version control system. You have to explicitly add it to version control. Only then will Git monitor - or track - the changes that happen to that file.

A file that is tracked in version control can, again, have two states:

• “unmodified” if it hasn’t been changed since it was last saved to the repository
• and of course “modified”, if there are (as we say) “local” modifications since it was last committed

These are the general states that a file can have in version control. Let’s see what this looks like in Tower.

Your current project’s files can be inspected in the “Working Copy” view.

By default, Tower only shows you files that currently have modifications. Because this is what you’re most interested in: seeing changes in your files. If you want to see all of your project’s files, you can configure this. You’ll then also see files that have not been modified recently.

So with what we’ve just learned in mind, we see that we’ve got one untracked file (that “new_page.html” file) - and a couple of tracked files with modifications.

Now, let’s go one step further: let’s save some of these changes to the repository, by making a commit.

This is where Git’s “Staging Area” comes in.

A new commit - a new version in the repository - consists of a set of changes. Before we can save such a new version, we have to explicitly tell Git which changes we want in that next commit.
To say it in a different way: just because a file was modified doesn’t mean it will automatically be part of your next commit. You have to mark them by adding them to the “Staging Area”.

So, let’s prepare our next commit: in Tower, we simply check the files we want to include. Let’s add “index.html”, the deletion of “error.html”, and that “new_page.html”.

Note that we deliberately left the changes in about.css unstaged. This means it won’t be included in the next commit. It will simply stay here as a local modification - and we might decide to add it to a later commit, refine it some more, or even discard it.

Now, let’s save these changes in a new commit: We type enter a sensible message that describes our changes - and hit the commit button.

The changes that we just added to the Staging Area are now saved in the repository. So they don’t show up here as modified, anymore.
By contrast, the changes we did not stage - those in about.css - are still here as local modifications.

Before we finish this video - why does the staging are exist? What is it useful for? To understand this, you have to know a golden rule of version control: Only commit related changes.

By contrast, this is how a commit message should NOT look like. If you mix up different topics in the same commit, you’ll make it very hard:

• to understand what happened here. Other developers will have a hard time knowing if this concerns them; and if there’s potential for trouble.
• to undo mistakes. Because you’ll have to undo all the other topics included in this commit, too.

That’s why a commit should only ever contain changes from a single topic. And the staging area makes it easy to craft a commit in this way.

This is it for today! Thanks for watching - and see you soon in our next video!