Commit: What is a Commit in Git?

What is a Git Commit?

A commit is the fundamental unit of Git history. It is an immutable snapshot of your entire project state at a specific point in time. Each commit is identified by a unique 40-character SHA-1 hash (often abbreviated to the first 7 characters) and contains the changes made to files, the author's identity, a timestamp, and a descriptive message.

The commit is at the heart of Git's philosophy. Where a simple Ctrl+S saves a file, a commit records a coherent set of changes with their context. It is the difference between saving and documenting. Each commit tells a part of the project's story: why that change was made, by whom, and when.

At KERN-IT, we consider commits the living documentation of our projects. A well-written commit history is as valuable as the code itself, as it allows understanding the technical decisions made over time and tracing the origin of every line of code.

Why Commits Matter

Commits are much more than simple backups. They constitute the complete logbook of your project and serve critical functions in the development process.

• Complete traceability: every change is attributed to an author with a precise date. In case of a bug, git blame identifies exactly who modified which line and when.
• Reversibility: commits allow returning to any previous state of the project. A problematic commit can be undone with git revert without losing history.
• Structured collaboration: commits are the basic unit of pull requests, merges, and code reviews. Good commit granularity significantly facilitates code review.
• Bug bisection: git bisect uses commits to identify, through binary search, the exact commit that introduced a bug. The more atomic the commits, the more precise this search becomes.
• Technical documentation: commit messages constitute chronological documentation of technical decisions, accessible to the entire team and future project developers.

How It Works

The Git commit process occurs in two steps. First, staging: you select the files or file portions you want to include in the commit with git add. This step allows you to create precise, atomic commits even if you have modified numerous files.

Then, the git commit -m "message" command creates the commit itself. Git calculates the SHA-1 hash from the file contents, directory tree, parent commit, and metadata (author, date, message). This unique hash guarantees the integrity of each commit: the slightest modification would produce a completely different hash.

The staging area (also called the "index") is an intermediate zone between your working directory and Git history. It gives you fine-grained control over what goes into each commit. The git add -p command even allows selecting specific portions (hunks) of a modified file.

The Art of the Commit Message

A good commit message is essential for project maintainability. The most widespread convention is the "Conventional Commits" format that structures the message according to the pattern type(scope): description. Common types include feat (new feature), fix (bug fix), refactor (refactoring), docs (documentation), test (adding tests), and chore (maintenance).

A good commit message answers the question "why" rather than "what." The diff already shows what changed; the message should explain the reason for the change. For example, "fix: prevent duplicate email sending on form retry" is far more useful than "fix email bug."

Concrete Example

A KERN-IT developer is working on a billing system. In a single day, they make several atomic commits on their branch:

• feat(invoice): add automatic VAT calculation based on client country
• feat(invoice): add PDF export with company branding
• test(invoice): add unit tests for VAT calculation edge cases
• fix(invoice): handle zero-amount line items in total calculation

Each commit is self-contained and coherent. If the PDF export causes problems, it can be reverted without affecting the VAT calculation. A colleague reviewing the PR can examine each commit separately, immediately understanding the intention of each change thanks to the clear messages.

Best Practices

1. Atomic commits: each commit should represent a single logical change. Do not mix a bug fix with a feature addition in the same commit.
2. Clear, descriptive messages: adopt a conventional message format (Conventional Commits) and explain the why of the change, not just the what.
3. Commit often: frequent, small commits are preferable to rare, massive ones. They facilitate review, debugging, and reversibility.
4. Verify before committing: use git diff --staged to review exactly what you are about to commit. Ensure no sensitive or temporary files are included.
5. Never commit secrets: passwords, API keys, and tokens should never appear in a commit. Use environment variables and an appropriate .gitignore file.

Conclusion

The commit is the pillar of Git and all modern software collaboration. Much more than a simple backup, it is an act of documentation that builds your project's history. Well-structured commits with clear messages facilitate code review, accelerate debugging, and allow any new developer to quickly understand the project's evolution. Mastering the art of the commit is investing in the quality and longevity of your code.