To Commit — What It Is, Formatting Rules, and Working with Git

What Is a Commit in Git

A commit in Git is an object that stores the state of project files at a specific point in time. Each commit contains a snapshot of all tracked files, a reference to the parent commit, and metadata. Unlike other version control systems, Git uses content-addressable storage — each object is identified by a SHA-1 hash of its content.

When a developer commits changes, Git creates a commit object that stores: a tree object (file structure), parent commit hash, author, committer, date, and message. This object is immutable — once created, a commit cannot be modified without changing its hash. This immutability guarantees the integrity of the project history.

# Stage changes and commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# View commit details
git log --oneline -3
git show HEAD

# Stage all changes and commit in one step
git commit -a -m "Update dependencies to latest versions"

Commits form a directed acyclic graph (DAG), where each new commit references the previous one. This allows navigating through history, reverting changes, and analyzing the evolution of the codebase. Understanding the structure of Git DAG is the foundation for advanced work with commits.

How to Properly Commit Changes

The commit process in Git consists of two stages: adding changes to the staging area (index) and creating the commit. The staging area allows the developer to select which specific changes will be included in the commit, even if many files have been modified in the working directory.

The atomicity rule is the key principle of a good commit. Each commit should contain one logical change. If a developer fixes a bug and refactors code — these should be two separate commits. Atomic commits simplify code review, change rollback, and history analysis.

Before committing, it is worth checking: whether any debug output, commented blocks, or accidental changes remain in the code. For this, the git diff --cached command is used, which shows what exactly will be included in the commit. An additional check with git status displays the list of files in the staging area.

• Check changes — git diff --cached shows what will be included in the commit
• Check quality — code should pass the linter and tests before committing
• Write a message — a clear description of the change's purpose
• Verify staged files — git status confirms the file list

Rules for Writing Commit Messages

The commit message is the documentation of the change for future developers. A good message answers the questions: what was changed and why. The Conventional Commits convention (Angular team, 2016) has become a standard for many projects and defines the format: type(scope): description.

A good commit message consists of a header (up to 50 characters) and a body (optional, up to 72 characters per line). The header is written in the imperative mood: “Add” not “Added” or “Adds”. Capitalization and a period at the end of the header are not used — this is an international Git convention.

A bad message: “fix things” or “update” — it carries no information. In a month, a developer will not be able to understand what exactly was changed and why. A good message: “fix(payment): handle timeout in stripe callback” — it immediately makes clear what and where was fixed.

Common Mistakes When Committing

Developers, especially beginners, often make typical mistakes when committing. The most common one is a commit that is too large, which mixes dozens of changes. Such a commit cannot be partially reverted, and code review becomes a nightmare.

The second most frequent mistake is a poor commit message. Messages like “fix”, “update”, “changes”, or “wip” do not provide context for future developers. In six months, no one will remember what exactly was fixed. The rule is simple: imagine that in a year you are looking through the history trying to find a specific change.

The third mistake is committing uncompiled or non-working code. After a commit, the code should at least compile. Not breaking the build is a basic requirement for any commit to a shared branch. For this, the build and tests are run before committing.

The fourth mistake is committing confidential data. API keys, passwords, and tokens should not end up in Git history. If a secret has already been committed, it needs to be not just removed in a new commit, but deleted from the entire history using git filter-branch or BFG Repo-Cleaner.

Advanced Techniques for Working with Commits

Git provides tools for managing commit history. One of the most useful is git commit --amend, which allows you to supplement the last commit with new changes or fix the message. This is convenient if the developer forgot to include a file or made a typo in the message.

# Fix last commit message
git commit --amend -m "fix(auth): correct token validation logic"

# Add missed file to last commit
git add missed-file.txt
git commit --amend --no-edit

# Interactive rebase for last 3 commits
git rebase -i HEAD~3

Interactive rebase is a powerful tool for rewriting history. It allows combining commits (squash), changing messages (reword), reordering (reorder), and deleting commits (drop). However, rebase modifies history, so it is used only on local commits that have not yet been pushed to a remote repository.

There are two approaches to reverting commits. git revert creates a new commit that undoes the changes of the previous one — a safe method that preserves history. git reset removes commits from history — dangerous if the commits have already been pushed. In team development, only git revert is used to undo published commits.