Making Commits

git commit takes everything in the staging area and saves it permanently as a new snapshot in the history, along with your name, the date and a message. Commits are cheap and easy to tidy up later, so make them often — each one is a point you can return to.

Your first commit

$ 
git add pancakes.txt omelette.txt
git commit -m "Add pancake and omelette recipes"
Output
[main (root-commit) d590b2f] Add pancake and omelette recipes
 2 files changed, 2 insertions(+)
 create mode 100644 omelette.txt
 create mode 100644 pancakes.txt

The summary tells you:

  • main — the branch the commit was made on;
  • root-commit — this is the first commit, with no parent;
  • the short hash of the new commit;
  • how many files changed and how many lines were added or removed;
  • create mode 100644 — a new file was created (100644 means an ordinary, non-executable file).

Afterwards, the working tree is clean again:

$ 
git status
Output
On branch main
nothing to commit, working tree clean

The next commit

$ 
echo "Pancakes: flour, milk, eggs, sugar" > pancakes.txt
git add pancakes.txt
git commit -m "Add sugar to pancakes"
Output
[main 1ab846a] Add sugar to pancakes
 1 file changed, 1 insertion(+), 1 deletion(-)

This time there is no "root-commit": the new commit's parent is the previous one. "1 insertion(+), 1 deletion(−)" is how Git describes a changed line — the old version removed, the new one added.

Only staged changes are committed

If you edit two files but stage only one, the commit contains only that one. The other stays modified in your working tree, ready for a later commit:

$ 
echo "Pancakes: flour, milk, eggs, sugar, salt" > pancakes.txt
echo "Omelette: eggs, butter, cheese" > omelette.txt
git add omelette.txt
git commit -m "Add cheese to omelette"
git status -s
Output
[main c03489f] Add cheese to omelette
 1 file changed, 1 insertion(+), 1 deletion(-)
 M pancakes.txt

Committing everything with -a

git commit -a stages every modified or deleted tracked file and commits in one step. It skips the staging area — handy for small changes, but it never includes untracked files:

$ 
git commit -am "Add salt to pancakes"
Output
[main 89180fd] Add salt to pancakes
 1 file changed, 1 insertion(+), 1 deletion(-)

(-am is -a and -m combined.)

Nothing to commit

$ 
git commit -m "Try again"
Output
On branch main
nothing to commit, working tree clean

Git refuses to make a commit with no changes. If you see "no changes added to commit", you have modifications but forgot to stage them.

Writing the message in an editor

Run git commit without -m and Git opens your editor (lesson 03) with a template:

TXT 
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# On branch main
# Changes to be committed:
#	modified:   pancakes.txt
#

Type the message at the top, save and close the file, and the commit is made. Lines starting with # are dropped. Leaving the message empty cancels the commit. The editor is the comfortable way to write a longer message with a summary line, a blank line and a body — the format explained in the next lesson.

You can also give several -m options; each becomes its own paragraph:

$ 
echo "Granola: oats, honey, nuts" > granola.txt
git add granola.txt
git commit -m "Add granola recipe" -m "Bakes in 25 minutes at 160 °C; store in an airtight jar."
git log -1
Output
[main 7ecef4f] Add granola recipe
 1 file changed, 1 insertion(+)
 create mode 100644 granola.txt
commit 7ecef4fa4e3de3a535b4af355bbd2e11499d2612 (HEAD -> main)
Author: Sam Rivera <sam@example.com>
Date:   Mon Mar 2 10:24:00 2026 +0000

    Add granola recipe

    Bakes in 25 minutes at 160 °C; store in an airtight jar.

How often to commit

A good rhythm is one commit per small, complete step: a bug fixed, a function added, a typo corrected. Small commits are easier to describe, review, understand later and undo on their own. If your message needs the word "and" to join two unrelated things, it was probably two commits. You can always combine small commits before sharing them (lesson 27); splitting a huge one apart is much harder.

Avoid committing things that don't belong in history at all: passwords and API keys, large generated files, and personal editor settings. Lesson 14 shows how to make Git ignore them.

Try it yourself

Make three separate commits in a test repository: one that adds a file, one that changes it, and one using -am. Then run git log --oneline to see your three commits, newest first.

Previousgit add