Back
GitoryxGitoryx
Beginner9 min read

Git Commit: The Complete Beginner's Guide

A commit is the fundamental unit of Git history. This guide explains what happens when you commit, how to write useful messages, and how to fix mistakes — everything a beginner needs to build good habits from day one.

The Problem

You've heard you should 'commit often', but you're not sure what a commit actually is, how to write a good message, or what to do when you realise your last commit was wrong.

Every commit is a permanent snapshot in your project's history. Good commits make bugs easier to track down, code easier to review, and history easier to understand weeks or months later. Bad commits — vague messages, giant diffs, mixed concerns — turn your history into noise.

Common mistakes developers make with this:

  • Writing commit messages like 'fix', 'wip', or 'stuff'
  • Committing everything in one giant dump instead of logical units
  • Forgetting to stage files before committing
  • Not knowing how to amend a commit after the fact

Gitoryx: Gitoryx shows your full commit history as a visual graph, making it easy to see what each commit changed, who made it, and how branches diverge over time.

What is Commit: The Complete Beginner's Guide?

A Git commit is a snapshot of your staged changes saved permanently in the repository's history. Each commit has a unique SHA hash, an author, a timestamp, and a message describing what changed.

Step-by-Step Guide

1

Stage your changes first

Before you can commit, you need to stage the changes you want to include. Nothing unstaged will appear in the commit.

bash
git add src/app.ts
# or stage everything:
git add .

Run `git status` first to see what's changed and what's already staged.

2

Create a commit with a message

The `-m` flag lets you write your commit message inline. Keep it short (under 72 characters) and describe *what* changed and *why*, not *how*.

bash
git commit -m "add login form validation"
3

Write a multi-line commit message

For larger changes, use a short subject line followed by a blank line and a more detailed body. Running `git commit` without `-m` opens your configured editor.

bash
git commit

# In your editor:
# Add login form validation
#
# - Validate email format on blur
# - Show inline error messages
# - Disable submit button until form is valid

The subject line should complete the sentence: 'If applied, this commit will...'

4

Stage and commit in one step

The `-a` flag auto-stages all tracked modified files and commits them. It does not include new (untracked) files.

bash
git commit -a -m "fix typo in header"

`git commit -a` skips the staging area. Use it only when you're sure you want to commit every change in every tracked file.

See this workflow in Gitoryx — Gitoryx screenshot

See this workflow in Gitoryx. See staged vs unstaged files clearly before committing

Free download
5

Amend the last commit

Made a typo in your message, or forgot to include a file? You can rewrite the last commit as long as it hasn't been pushed yet.

bash
# Fix the commit message
git commit --amend -m "add login form validation with email check"

# Add a forgotten file to the last commit
git add src/validation.ts
git commit --amend --no-edit

Never amend a commit that has already been pushed to a shared branch. It rewrites history and will cause problems for your teammates.

6

View your commit history

Use `git log` to see past commits. The `--oneline` flag gives a compact view.

bash
git log --oneline

# a3f2c1d add login form validation
# 9b1e4fa init project structure
# 7c0d2ae initial commit

Common Mistakes to Avoid

Vague commit messages

'fix', 'update', 'changes' — these messages tell you nothing when you're debugging three months later.

Fix: Write messages that answer: what changed, and why? Example: 'fix null pointer in user login when session expires'.

One massive commit for unrelated changes

Mixing a bug fix, a refactor, and a new feature in one commit makes history hard to read and reverts painful.

Fix: Use `git add -p` to split changes into separate, focused commits.

Amending already-pushed commits

Amending rewrites the commit SHA. If that commit is on a shared branch, teammates will face a diverged history.

Fix: Only amend commits that exist only in your local branch, or use `git revert` for pushed commits.

Gitoryx — visual Git client for macOS, Windows & Linux
GitoryxGitoryx — macOS, Windows & Linux

Commit with confidence in Gitoryx

  • See staged vs unstaged files clearly before committing
  • Visual commit graph shows your history at a glance
  • One-click amend for the last commit
  • Commit message templates to enforce team conventions
Download Gitoryx — FreemacOS · Windows · Linux · No subscription

Frequently Asked Questions

What is the difference between `git add` and `git commit`?

`git add` moves changes into the staging area. `git commit` saves the staged changes as a permanent snapshot in the repository history. You always need to `git add` before `git commit`.

How do I undo my last commit without losing my changes?

Use `git reset --soft HEAD~1`. This removes the last commit but keeps all changes staged, so you can re-commit them with a corrected message.

What should a good commit message look like?

A good subject line is under 72 characters, written in the imperative mood ('add feature' not 'added feature'), and describes what the commit does. For complex changes, add a blank line and a body with more context.

Can I commit only some files?

Yes. Stage only the files you want with `git add <file>`, then commit. Files you didn't stage won't be included.

See it in action with Gitoryx

Everything in this tutorial is faster and clearer with a visual Git client. Gitoryx is free, runs natively on macOS, Windows, and Linux, and built for developers who want to move fast without breaking things.