Anyone who has successfully used Git in any form has probably used the
git commit. In its most basic form, with just a commit message,
this does a few things: it stores the files in the staging area, or index,
in a new commit with a log message from the user, which is supposed to
describe the changes (but is more often than not “asdf”) and it updates
the current branch to have a head at the latest commit. Simple, right?
Wait, what does any of that mean? “Storing files in the index in a commit”? Well, Git is all about being lightweight and not storing anything it doesn’t need to, so this means that Git doesn’t want to have complete copies of every single file for every single commit. You might ask, why not just store what changed? This would be correct for most other version control systems like CVS, Subversion, Perforce, Bazaar, etc., but Git doesn’t do this. Git takes “snapshots” of the files in the directory you’re tracking. A snapshot will just include a pointer to a previous snapshot if a particular file hasn’t changed, but will store new versions. If you were to look at the actual data of a commit, you would see the content of all the files that Git is tracking. This supposedly makes Git more powerful in terms of branching, but that’s for another day.
Anyway, Git stores a beautiful “snapshot” in the local repository, then
it also changes the contents of two files to be the commit hash
(the 40-character fa90c29… that you see after the commit happens).
These files happen to be
.git/refs/heads/<current branch name> and
which are just Git’s place to store the head of the specified branch
(note, it’s a pointer, not a full commit) and the head of the current branch.
So, Git has created a new commit and updated a branch head. What about the other things that you can do? Answer is: way more than you ever wanted to do or even think about. Commit has a number of parameters, as can be seen in the synopsis of the help page:
How do we read this? It means
git commit can be followed by these things. Let’s take them one brace at a time:
[-a | --interactive | --patch]: these say how to choose which files to look at.
just looks at the index, but adding -a will look at all files in the working
directory that are also in the index, and stage changes in modified files.
--interactive or --patch will give you an interface to choose which changes to commit.
-s/--signoff: this will automatically add a signed-off by line by the
committer at the end of the commit message. This typically is used to certify
that a committer has the rights to submit the particular commit
-v/--verbose: this will show the diff between the current HEAD commit
and what would be committed at the bottom of the message template that is
generated, useful for writing commit messages so you can see what you did.
-u[<mode>]/--untracked-files[=<mode>]: shows the untracked files. The
mode can be
no: show no untracked files,
normal: show untracked files
in the root directory and untracked directories, and
all: show all
untracked files, even those in untracked directories. Usage looks like
git commit -uno or
git commit --untracked-files=all. The default when using
is all and when not using it, the default is
--amend: this one is to be used responsibly. If you ‘accidentally’ wrote “asdf”
as your commit message, or forgot to include a file in a commit, you can
amend the head of the current branch with this. If you do
git commit --amend,
command line will pull up an editor that has the previous commit message already in it,
then once you finish writing your commit message, this new commit will replace the
old head of the current branch. This commit will have the same parent(s)
and authors as the current commit, but DO NOT USE if this commit has already
been published. Rewriting history is bad.
--dry-run: this is for those who don’t have Git magic (e.g. me, you, everyone…)
and want to know what the heck will happen when you press enter with a
complicated command. For example,
git commit -a --dry-run will show you
all files that will be committed or not if you run the command
git commit -a.
[(-c | -C | --fixup | --squash) <commit>]:
will reuse the log message and authorship from
does the same thing as
-C, but will show you the editor before actually making changes.
--fixup=<commit> will make a commit that is to be used with rebase
with the message of
<commit> prefixed by “fixup! ”. Finally
does the same thing as
--fixup, but uses the prefix “squash! “, and can be used
with the options
[-F <file> | -m <msg>]: this specifies the message of the commit.
will take the commit message from the specified files,
will take it from the next input. For example:
git commit -m “Added 9001 files and beat Goku in single combat”
adds a commit with that message.
--reset-author: this is used with the
--amend options, and will
make the author of the commit you, rather than whoever made the commit you’re changing.
--allow-empty: this allows you to commit with no changes. Not recommended by me.
Whew… halfway! We’ll cover the rest in the next iteration of this post.