Imagine working on a project without checkpoints. Every change is just piling up, and if one small mistake occurs, it could mean hundreds of hours of work down the drain. That’s where git commit comes in.
A ‘git commit’ is a snapshot of your project that saves your work progress at certain points. It contains a time-stamped record, uniquely identified by a cryptographic hash (SHA), and contains information about what was changed in the code, when, and who made that change. It allows you to roll back, compare versions, or keep a clean, trackable version history
In this guide, we’ll tell you what git commit does, why it’s important, how it fits into the whole workflow, and tips to write better commits while avoiding mistakes.
Table of Contents:
What Is Git Commit
“A commit is like a save point in your project. It records a snapshot of your files at a certain time, with a message describing what changed”.
In Git, a git commit means a snapshot of your repo at a specific point in time. Prior to the execution of git commit, the git add command is used to promote or ‘stage’ changes to the project that will be stored in a commit. These two commands, git add and git commit, are two of the most frequently used.
Git Commit Syntax
The general syntax for committing changes in Git is
git commit -m "Your commit message here"
git commit tells Git to save a snapshot of the staged changes in your local repository.
-m lets you provide the commit message directly in the command line.
The message should clearly describe what the commit does (e.g., “Add login form validation”).
If you don’t use -m, Git will open your default text editor and prompt you to type the commit message there.
Git Commit Options and Flags
The git commit command can be customized with different options (or flags) to make commits faster, more specific, or more flexible. Here are some of the most useful ones:
1. -m — Add a Message Inline
Syntax:
git commit -m "Your commit message"
What it does:
Lets you include the commit message directly in the command, skipping the text editor.
When to use it:
For quick commits, where you already know the message.
Common in small updates or when scripting Git commands.
Why it’s useful:
Saves time and avoids opening an editor.
2. -a — Commit All Tracked Changes
Syntax:
git commit -a -m "Message"
What it does:
Automatically stages and commits all modified tracked files (files Git already knows about).
When to use it:
When you want to skip the separate git add step for tracked files.
Why it’s useful:
Speeds up the workflow for frequent commits, but still leaves out new, untracked files (which must be added manually).
3. Git Commit Amend — Modify the Last Commit
Syntax:
git commit --amend
What it does:
Reopen your last commit so you can change its message or add more changes.
When to use it:
- To fix typos in commit messages.
- To add forgotten changes before pushing.
Why it’s useful:
Keeps your git commit history clean by avoiding small “oops” commits.
Caution: Avoid amending commits that are already pushed to a shared branch; it rewrites history and can cause conflicts.
4. -p or —patch Commit Parts of a File
Syntax:
git commit -p
What it does:
Let’s you interactively choose which changes (hunks) to commit, even within the same file.
When to use it:
When you want to split unrelated changes into separate commits.
Why it’s useful:
Helps keep commits focused and logical, which makes reviewing and debugging easier.
Interactive Commits with git add -p
Sometimes you don’t want to commit everything you’ve changed, especially if your edits include fixes, experiments, or unrelated tweaks.
This is where interactive commits come in handy, and the git add -p command is your go-to tool.
1. Staging Changes Selectively
When you run:
git add -p
Git will break down your modified files into small sections called hunks.
For each hunk, Git will ask:
- y — Stage this hunk.
- n — Skip this hunk.
- q — Quit.
- a — Stage all remaining hunks.
- d — Skip all remaining hunks.
- s — Split this hunk into smaller pieces.
This lets you pick exactly which changes go into the next commit, even if they’re in the same file.
2. Reviewing Changes Before Committing
Using git add -p forces you to review each change one by one before committing.
This helps you:
- Catch mistakes before they end up in your commit history.
- Keep commits small and focused on a single purpose.
- Avoid mixing unrelated changes in the same commit.
For example:
If you’ve updated app.js with both a bug fix and a UI tweak, git add -p allows you to commit the bug fix now and save the UI tweak for a later commit.
Pro Tip: Combine git add -p with clear commit messages to keep your Git history clean, easy to read, and reviewer-friendly.
Git commit vs SVN commit
Although they share the same name, a Git commit works very differently from an SVN commit. This can be confusing for developers moving from SVN to Git. The primary difference lies in the design of the two systems: SVN employs a centralized model, whereas Git utilizes a distributed model.
In SVN, committing means sending your changes from your local machine directly to a central repository where everyone works. In Git, committing only saves a snapshot of your changes to your local repository. It doesn’t interact with any other repositories at this stage. If you want to share your changes with others, you push those commits later to any remote repository you choose.
How Git Commit Works
You can think of Git as a tool for managing your project’s timeline. Commits are the building blocks of that timeline, snapshots or milestones that capture your project at a specific moment. When you run the git commit command, Git saves the current state of your files to your local repository.
This is different from SVN, where committing the code sends your changes straight from your working copy to a central repository. In Git, commits stay local until you decide to push them to a remote repository. The staging area acts as a buffer between your working directory and your project history, and your local repository acts as another buffer between your work and any shared repository.
This changes how development works. Instead of committing directly to the central repo, you can make multiple commits locally before sharing them. This has several benefits:
- You can break a feature into smaller, focused commits.
- Related changes can be grouped together.
- You can clean up your history before making it public.
- You can work in isolation without affecting others until you’re ready.
Here are some key commands for commits:
- git commit -m “message” – Commit staged changes with a message
- git commit -a -m “message” – Commit all tracked changes (skip staging)
- git log – See commit history
Even though Git allows you to delay integration, it’s still best for teams to integrate often and in small, manageable units. This keeps collaboration smooth and avoids messy conflicts later on.
Use Cases of the Git Commit Command
1. Keeping a History
Commits create a detailed timeline of your project. You can see what changed, when it changed, and can even go back to an older version if needed.
2. Working with a Team
When you commit your changes, your teammates can see what you did. You can also see their work and combine it with yours without losing anything.
3. Marking Checkpoints
Commits act like save points in a game. You can mark important moments in your project, making it easier to find and return to them later.
4. Tracking Who Did What
Each commit shows who made the change and when. This is useful for accountability, project tracking, and knowing who to ask about specific updates.
Git Uses Snapshots, Not Differences
One of the biggest differences between Git and SVN is how they keep track of your project’s history. SVN uses a difference-based model, while Git works with snapshots.
In SVN, each commit only records the changes (or “diffs”) made since the last version. In Git, every commit saves a full copy of each file as it exists at that moment, like taking a complete photo of your project’s state.
This approach makes Git much faster in many cases. When you want to see a specific version, Git does not need to rebuild it from a list of changes. Instead, it can instantly pull the full version straight from its database.
Because of this snapshot-based design, almost everything in Git, from branching and merging to team collaboration, becomes more efficient and flexible compared to difference-based systems like SVN.
Common git commit Options
Git gives you a few different ways to commit changes, depending on how you like to work. Here’s what they do and when you might use them:
1. git commit
This is the basic git commit command. It takes whatever you’ve staged and commits it. Git will open your default text editor so that you can type in a message describing the change or changes. Once you save and close, the commit will be done.
2. git commit -a
Think of this as “commit everything I’ve changed so far”, but only for files Git is already tracking. You don’t need to run git add for modified files, but if you created a brand-new file, you’ll still have to add it first.
3. git commit -m “message”
This skips the text editor and lets you write the commit message right in the command. It’s quicker, but try to make the message meaningful, not just “update” or “fix.”
4. git commit -am “message”
This is a time-saver. It stages all tracked file changes and commits them with your message in one go. Just remember, it still ignores new files that haven’t been added before.
5. git commit –amend
If you just made a commit and realized you forgot something or made a typo in the message, this is your fix. It updates your last commit instead of creating a new one. Don’t use this on commits you’ve already pushed to a shared repo, it can cause headaches for others.
Pro tip: While -a and -am are great shortcuts, staging changes manually with git add gives you more control and keeps your commit history clean. This makes it easier to review, undo, or track specific changes later.
Example: Saving Changes with a Commit
Let’s say you’ve updated a file called hello.py on your current branch and now want to save those changes to the repository history. In Git, this is a two-step process: stage the changes, then commit them.
Step 1: Stage the file
git add hello.py
This command moves hello.py into Git’s staging area, meaning it’s now marked to be included in your next commit. You can confirm this by checking the repository status:
git status
You might see something like:
On branch main
Changes to be committed:
(use “git reset HEAD <file>…” to unstage)
new file: hello.py
The green text tells you that hello.py is staged and will be saved when you commit.
Step 2: Create the commit
git commit
When you run this, Git opens your configured text editor (set via git config) so you can write a commit message. The editor will also show a list of staged changes for reference, for example:
# Please enter the commit message for your changes. Lines starting
# with ‘#’ will be ignored, and an empty message aborts the commit.
# On branch main
# Changes to be committed:
# modified: hello.py
Writing a Good Commit Message
Git doesn’t force a specific format, but a widely accepted convention is:
- Subject line: A short summary of the change, ideally under 50 characters.
- Blank line: Separates the summary from the body.
- Body: A more detailed explanation of what and why you changed, if needed.
For example:
Improve the greeting in hello.py
– Update sayHello() to include the user’s name
– Make sayGoodbye() more friendly and personal
Think of the first line as the “headline” and the rest as the “story.” Many developers also write commit messages in the present tense (e.g., “Add feature” instead of “Added feature”) because it reads more like a command or an action applied to the repository. This style also makes history review and rewrite commands feel more intuitive.
Git Commit Examples
1. Single-file commit
git add file1.txt
git commit -m "Add file1 with initial content"
Stages and commits only file1.txt.
2. Multiple-file commit
git add file1.txt file2.txt
git commit -m "Update file1 and add file2"
Stages and commits changes from multiple files together.
3. Amending a commit
git commit --amend -m "Update commit message and include new changes"
Modifies the last commit, either to update its message or include additional changes.
Git Commit vs Git Push
| Feature |
Git Commit |
Git Push |
| Purpose |
Saves changes to your local repository |
Sends local commits to a remote repository |
| Scope |
Only affects your machine |
Updates the shared remote repo for others to see |
| When Used |
After staging changes with git add |
After committing changes locally and ready to share |
| Requires Internet? |
No |
Yes (to connect to the remote repo) |
How They Work Together
Think of git commit as saving your work locally, and git push as publishing your saved work for others.
Typical Workflow:
git add file.txt # Stage changes
git commit -m "Fix bug" # Save locally
git push origin main # Send commits to remote
- You can make multiple commits locally before pushing.
- Pushing uploads those commits in the order you created them.
Common Git Commit Errors and Fixes
1. Empty Commit Messages
Problem:
You try to commit, but Git rejects it because there’s no commit message.
Fix:
Always add -m “Your message” when running git commit, or write one in the editor that pops up. Example:
git commit -m "Fix login form validation"
2. Detached HEAD State
Problem:
You check out a specific commit instead of a branch, and your changes aren’t tied to any branch.
Fix:
Switch back to a branch before committing
git switch main
Or create a new branch from the current commit:
git switch -c new-branch
3. Overwriting History
Problem:
Using commands like git commit —amend or git push —force can overwrite commit history, causing problems for collaborators.
Fix:
- Only amend commits you haven’t pushed yet.
- Avoid —force unless you’re sure it’s safe.
- Use —force-with-lease to reduce risk.
4. Committing Unwanted Changes
Problem:
Accidentally including debug logs, test files, or sensitive data.
Fix:
- Use git status before committing to review changes.
- Add files to .gitignore to prevent accidental commits.
5. Too Many Changes in One Commit
Problem:
Large commits make it harder to review or revert changes.
Fix:
- Stage changes selectively with:
git add -p
- and commit related changes separately.
How to Delete a Git Commit
You can delete a Git commit in a few ways, depending on where the commit is and whether it’s been pushed to a remote repository.
1. Delete the Most Recent Commit (Local Only)
If you want to remove the last commit but keep your changes in the working directory:
git reset --soft HEAD~1
If you want to remove the commit and the changes:
git reset --hard HEAD~1
2. Delete Any Commit (Rewriting History)
If the commit is not the latest, use interactive rebase:
git rebase -i HEAD~n
- Replace n with the number of commits to go back.
- Change pick to drop next to the commit you want to delete.
- Save and exit.
3. If Commit Has Been Pushed to Remote
If others have pulled it, deleting it will rewrite history and may cause conflicts. Use force push only if you’re sure:
git reset --hard <commit_id_before_the_bad_one>
git push origin branch-name --force
Note: Never force-push to a shared branch (like main) unless you’ve coordinated with your team. If you just want to undo changes without rewriting history, use git revert <commit_id> instead; it creates a new commit that undoes the old one.
Difference between Commit and Save
Save (Traditional File System):
When you hit “Save” in a regular program, it just updates the file on your computer with the new content. If the file didn’t exist before, it creates it. It’s a simple overwrite, and this lets the old version go.
Commit (Git):
A commit in Git is like taking a picture of your project at a specific moment. Instead of replacing old files, Git stores a new snapshot of all the changes you’ve staged. It also remembers who made the changes, when they were made, and why (from your commit message). Over time, these snapshots stack up to create a full history of your project, so you can go back and see or restore any earlier version.
Conclusion
The git commit command is one of the most important parts of using Git. Before you commit, you first use the git add command to choose which changes you want to include. Then, git commit saves a snapshot of those changes, adding it to your project’s history. You can check what’s staged and ready to commit at any time by running git status. If you’ve used SVN before, it’s worth noting that Git and SVN handle commits very differently, even though they use the same word. In Git, commits are quick, local actions, so you can commit as often as you like without slowing things down. In SVN, committing is slower because it sends your changes to a central server right away.
Git Commit Explained – FAQs
1. What is Git Commit in git?
A Git commit is a fundamental operation in the Git version control system that records changes to a repository. It represents a specific version of the project at a given point in time, essentially a “snapshot” of the project’s state. Each commit is uniquely identified by a cryptographic hash (SHA) and contains information about the changes made, when they were made, and by whom.
2. How is git commit different from git push?
git commit only saves changes to your local repository. git push uploads those commits to a remote repository, making them available to others.
3. How do I undo the last git commit?
If you haven’t pushed it yet, run:
git reset --soft HEAD~1
This removes the commit but keeps your changes staged.
4. Can I commit without staging changes in Git?
Yes. Using:
git commit -a -m "message"
will automatically stage all modified tracked files and commit them in one step.
5. What’s the difference between git commit and git add?
git add stages changes to be included in the next commit, while git commit actually saves those staged changes into the repository history.
6. How do I write a good git commit message?
Start with a short summary (under 50 characters), leave a blank line, and add details in the body if needed. Use the present tense for clarity.
7. Can I change the last commit message in Git?
Yes. Run:
git commit --amend
This lets you edit the message or add changes to the previous commit. Avoid using it after pushing to a shared branch.