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:
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.
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.
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.
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. |