Tracking Change

git status

It is time to get familiarized with another git command. In the command line, run:

git_basics/ $ git status

If you're following along from the previous chapter, your output should read as follows:

# On branch master
#
# Initial commit
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       .gitignore
#       LICENSE.md
#       README.md
nothing added to commit but untracked files present (use "git add" to track)

Reviewing this message from top to bottom we know the following:

We are on something called a branch named master. We will learn more about branches in the next chapter, but for now, just internalize the phrase a branch named master.
The three files we created are untracked and we can start tracking them with the command git add <file>. Perfect. We will add these files like the output suggests.

The output from git status is showing us what's called our working tree and staging area. As we saw in the output above, we have new files in our working tree that we'd like to commit to our repo.

Creating a commit

What's a commit?
You can think of a commit as a bundle of changes. A commit can contain changes across many files, it can contain the addition of new files, as well as the deletion of existing files. In git, we're always moving commits around, pushing them, pulling them and merging them. We'll cover this in more detail later, but for now, just think of a commit as a way to logically group a bundle of various changes together.

We're now ready to create our first commit to our repository. But first, we must tell git which files should be included in this commit. From the command line type:

git_basics/ $ git add .gitignore README.md LICENSE.md

The above will stage the 3 files. Do a quick git status. You should now see that those three files are staged, ready to be committed. At this point, it's safe to keep making changes to those files, but if you do, you will have to stage the changes again, ready to be included into the next commit. When you're done making changes, and you've staged the affected files, go ahead and wrap those staged files into a commit:

git_basics/ $ git commit -m 'Add first project files'

You just made your first repository commit! The output should look like this:

[master (root-commit) f5e1695] Add first project files
 3 files changed, 4 insertions(+)
 create mode 100644 .gitignore
 create mode 100644 LICENSE.md
 create mode 100644 README.md

To clarify what just happened, the git commit command commits all of the changes which we have staged into our repository. Each time you make a change to a file, you will need to stage the changes using the git add <file> command again. Being able to stage changes individually allows you to make lots of changes without worrying about committing them immediately. When you are ready, you can commit all the staged files all at once.

As you may have guessed, the -m flag allows you to attach a message to the commit. This message will serve as a note stating the reason for the change, so it should provide an adequate description of the changes being committed.

It is very important for you to remember that any unstaged changes are not tracked by git. That means that when you create a file, git does not know about it until you git add it, and after you make changes to it, the same applies.

git log

Any time you would like to see a commit history for your repo, you can do so using the git log command:

git_basics/ $ git log

You will be presented with a history of commits in this repository. Each entry will contain the hash which uniquely identifies each commit, along with the author, date, and commit message:

commit 9389be5314809c7be9054706d1618b458dc9a800
Author: joesmith2444 <joesmith.2444@example.com>
Date:   Tue Oct 14 23:18:34 2014 -0700

    Update README

commit 5afaf121fe74c35d4e3fb5543773bf8b359e4b80
Author: Joe Smith <joesmith.2444@example.com>
Date:   Tue Oct 14 23:02:14 2014 -0700

    Add first project files

In some teams, commit hygiene is highly regarded so it's important to make sure each commit contains a logical grouping of changes (eg, a bug fix or a feature) with a clear commit message. When anyone issues git log on the repository, a clear historical list of commits appears.

Summary

To summarize, here are the steps to create commits in your local git repository:

Command	Description
git status	Run this command any time and often to check on the status of the files in the git repository.
git add	This command stages changed files, readying them to be wrapped into the next commit.
git commit	This command commits staged files, wrapping them into a commit. A historical record of commits is what we refer to as a codebase's version or commit history.
git log	View the repository's commit history.

Next: Branching