git commit

You've staged your changes with git add, and now you're ready to save them to your repository's history. git commit creates a permanent snapshot of everything in your staging area, along with a message describing what you changed and why. Unlike saving a file in an editor, commits are immutable records that become part of your project's timeline. Once you commit, those changes are preserved in Git's history, making it easy to review, revert, or understand what happened later.

The basic form is git commit -m "Add user authentication", where the -m flag lets you write your commit message directly in the command. The message should describe what the commit does and ideally why you made the change. Good commit messages help your teammates (and future you) understand your reasoning without having to read through all the code changes. Instead of "fix bug," write "Fix login redirect loop when session expires" so it's clear what problem you solved.

If you skip the -m flag and just run git commit, Git opens your default text editor where you can write a longer, more detailed message. The first line should be a brief summary (50 characters or less), followed by a blank line, then a more detailed explanation if needed. This format works well for complex changes that need more context. Many teams have conventions about how to format these messages, like starting with a verb in the imperative mood (Add, Fix, Update) or including ticket numbers.

Amending and Refining Commits

Sometimes you commit too early and realize you forgot to include a file or made a typo in your code. Running git commit --amend lets you add new staged changes to your most recent commit, or just update the commit message. If you've staged new changes, they get folded into the previous commit as if you'd included them from the start. If you haven't staged anything, you're just editing the message. This is handy for small fixes before you push your work, but be careful—amending changes the commit's identity, so don't amend commits you've already pushed to a shared branch.

The -a flag provides a shortcut for committing all changes to tracked files without explicitly staging them first. Running git commit -a -m "Update API documentation" automatically stages all modifications to files Git is already tracking, then commits them. This doesn't include new untracked files—you still have to git add those explicitly. Many developers use -a for quick commits when they know all their changes belong together, though it's safer to review with git add and git status for important changes.

Pull Request Context

In pull request workflows, each commit tells part of your story. Reviewers look at your commits to understand how you built the feature, not just what the final result looks like. Clean, focused commits make reviews faster because each one solves a specific problem or adds a specific feature. Instead of committing everything at once in a single "implement feature" commit, you might make separate commits for "Add database schema," "Implement API endpoints," and "Add frontend components."

Some teams enforce commit message conventions through Git hooks or CI checks. They might require that messages reference a ticket number like "PROJ-123: Add password reset flow" or follow a specific format like Conventional Commits (feat:, fix:, docs:). If your commit message doesn't match the pattern, the commit is rejected, and you need to amend it. These conventions make it easier to generate changelogs, track which changes relate to which issues, and maintain consistent history across the team.

Empty commits are possible with git commit --allow-empty -m "Trigger CI rebuild", which creates a commit with no changes. This is occasionally useful for retriggering CI pipelines or marking specific points in history, but it's uncommon in day-to-day work. Most commits should contain actual changes.

Commit Signing and Verification

Some organizations require signed commits using GPG or SSH keys. When enabled, running git commit -S -m "message" signs the commit cryptographically, proving that you're the author. Platforms like GitHub display a "Verified" badge next to signed commits, which helps prevent impersonation and ensures commits haven't been tampered with. If your team uses signing, you'll configure your GPG key once, and then adding -S (or setting it as default) becomes part of your commit workflow.

The key to effective commits is thinking of them as documentation. Each commit should be a logical unit of work that makes sense on its own. If you're fixing a bug, the commit should contain only the fix, not unrelated cleanup or new features. If you're adding a feature, break it into steps that each leave the codebase in a working state. This discipline pays off during code review, when debugging, and when you need to roll back changes without losing unrelated work.

Commits are your project's memory. They capture not just what changed, but when and why. A well-crafted series of commits tells the story of how your feature came together, making it easy for anyone (including future you) to understand the evolution of your code.