Staging & Committing Changes [Learn Git Video Course]

Learn about Git’s Staging Area: how can you add changes to the next commit and how can you save changes as a new revision in your repo? This video is part of our free 24-part video course on Learning Git on the Command Line.
Subscribe ► https://www.youtube.com/channel/UCrl5xG-L4ZCFkR-bhUy9BVg?sub_confirmation=1

***************************************

Additional Git tutorials and resources

Learn Git on the Command Line: a free 24-part video course ► https://www.youtube.com/playlist?list=PLyCj4RCToz5DRDx3sJ4iW9i8D2G8OdHYH

Surviving with Git: https://www.youtube.com/playlist?list=PLyCj4RCToz5AKiAKycmAZcTZron_yANQT

More Productive in Git with Tower: https://www.youtube.com/playlist?list=PLyCj4RCToz5A_1RzK7MfNHSQr65FxmSGR

***************************************

Welcome to our video series on learning version control with Git. 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...

In our last episode, we met the "git status" command. Let's execute it again.

With what we 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: we type "git add" and the names of the files we want to include. Let's add "index.html" and that "new_page.html". To confirm the deletion of error.html, we have to use "git rm".

Let's see what "git status" tells us now. You'll notice that there's a new paragraph, headed "changes to be committed".
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 "git commit" and, for the "-m" parameter, we need to enter a sensible message that describes our changes.

Let's have one more look at "git status": All of 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.
...and you'll make it hard 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!

SUBSCRIBE to learn more about Git, Tower & how to become a better developer!
https://www.youtube.com/channel/UCrl5xG-L4ZCFkR-bhUy9BVg?sub_confirmation=1

For more free ebooks, cheat sheets, and video tutorials make sure to check out our FREE learning platform! https://www.git-tower.com/learn/

STAY UP-TO-DATE:
Tower: https://www.git-tower.com
Twitter: https://twitter.com/gittower
Facebook: https://www.facebook.com/gittower

#git #learngit #gittutorial