git commit

A commit takes the index, not the folder#

Between your files and the history there is an intermediate layer — the index, also called the staging area. git add copies the current contents of a file there, and git commit writes into history exactly what is in the index at the moment you run it. This is where beginners get surprised: if you edit a file again after git add, the commit gets the earlier version, and the new one stays in the working directory. git status shows both lists separately — "Changes to be committed" and "Changes not staged for commit".

So the order is: look at git status, select what you need with git add, check with git diff --staged, and only then commit.

Syntax#

git add README.md app.py
git commit -m "Add first version of argument parsing"

Option	What it does
-m "text"	the message right in the command, no editor
-a	take every change to already tracked files, skipping git add
--amend	replace the last commit with a new one instead of adding another
--no-edit	with --amend, keep the previous message
--allow-empty	make a commit with no changes (sometimes needed to trigger checks)
-v	show the diff itself in the editor — handy for a last read-through

-a does not pick up new files: anything Git does not know about yet has to be added by hand. Write messages in the imperative mood and to the point — a first line of about 50 characters, details after a blank line.

Example: the first commit in a new repository#

git init
git add README.md
git commit -m "Describe the project"

[main (root-commit) 4f1c2ab] Describe the project
 1 file changed, 12 insertions(+)
 create mode 100644 README.md

In the brackets are the branch and the short hash. The very first commit is marked root-commit: it has no parent.

Example: fixing the commit you just made#

Forgot a file or made a typo in the message? You do not need another commit called "fix typo":

git add tests/test_args.py
git commit --amend --no-edit

[main 9d31c07] Add first version of argument parsing
 Date: Sat Sep 20 11:04:18 2026 +0300
 2 files changed, 41 insertions(+)

The hash has changed — this is a different commit, and the old one is simply no longer needed. Hence the rule: --amend is safe as long as the commit has not been pushed. What to do if it already has is covered in the article on git push.

What Git complains about#

nothing to commit, working tree clean — the index is empty and there is nothing to change. Usually you forgot git add.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	notes.txt

nothing added to commit but untracked files present

The file is new and Git does not track it. Either add it, or put a pattern into .gitignore if it ended up in the folder by accident.

Please tell me who you are — your name and email are not set. You fix this once per machine:

git config --global user.name "Jane Doe"
git config --global user.email "jane@example.com"

Aborting commit due to empty commit message — you closed the editor without writing anything. Git deliberately refuses to record a commit without a message.

How to undo a commit#

It all depends on whether the commit has reached the server.

git reset --soft HEAD~1

This removes the last commit but keeps the changes in the index — you can commit again right away. --mixed (the default) puts the edits back into the working directory, and --hard erases them together with the commit; it is the only really dangerous one of the three.

git revert 9d31c07

This creates a new commit that cancels the given one. It does not rewrite history, so it is the right tool for something your teammates have already seen. All the options are compared in how to undo a commit.

If you are lost and it feels like work is gone, look at git reflog: it lists every state of HEAD over the last few weeks, and almost any "missing" commit can be found there by its hash.

Step-by-step plan

1. See what changedgit status and git diff: first understand what the commit should be made of.
2. Stage your selectiongit add file by file; check the selection with git diff --staged.
3. Record with a messagegit commit -m with a meaningful first line of up to 50 characters.
4. Check the historygit log --oneline -3: the commit is there, the branch has moved.
5. Fix it if neededBefore pushing — git commit --amend; after pushing — git revert.

Check yourself

Sources

• Pro Git bookThe section “Recording Changes to the Repository”
  free
• git commit referenceEvery option and the message format
  free
• How to Write a Git Commit MessageSeven rules for commit messages that read well in the log
  free

Was this helpful?

Yes No