Version Control with Git

Some Notes on Using git commit

Using git commit --all

The -a or --all option to git commit causes it to automatically stage all unstaged, tracked file changes—including removals of tracked files from the working copy—before it performs the commit.

Let’s see how this works by setting up a few files with different staging characteristics:

# Modify file "ready" and "git add" it to the index
# edit ready
$ git add ready

# Modify file "notyet", leaving it unstaged
# edit notyet

# Add a new file in a subdirectory, but don't add it
$ mkdir subdir
$ echo Nope >> subdir/new

Use git status to see what a regular commit (without command-line options) would do:

$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   ready
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#
#       modified:   notyet
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#       subdir/

Here, the index is prepared to commit just the one file named ready, because it’s the only file that’s been staged.

However, if you run git commit --all, Git recursively traverses the entire repository; stages all known, modified files; and commits those. In this case, when your editor presents the commit message template, it should indicate that the modified and known file notyet will, in fact, be committed as well:

# Please enter the commit message for your changes. # (Comment lines starting with '#' will ...