Skip to content

Edit Commits Example


What Will We Learn?

Learn how to safely edit, amend, and reorganize Git commits using --amend and interactive rebase. You’ll also learn the right workflow, precautions, and best practices for rewriting commit history confidently. Theory is okay but Don’t Skip The Practical.

What Does It Mean To Edit Commits?

Editing commits simply means to amend or update the commit doing either of them:

  • Updating commit message (editing message for more clarity)
  • Updating commit state (adding new files, modify files, etc.)

This is useful for fixing typos, forgotten files, or improving commit messages before pushing.

Edit a Commit With --amend

Say, your commit history looks like:

    gitGraph
    commit id: "abc123 Initial Commit, First Deploy"
    commit id: "def456 chore: fix typo in documentation"
  

You realize that commit the last commit def456 message should be of type docs instead of chore. So, insted of introducing third commit, you --amend or update the second commit with more meaningful message like:

docs: fix typo in documentation

The command you need here is:

git commit --amend -m 'docs: fix typo in documentation'

Git now updates the commit message and now your history looks like:

    gitGraph
    commit id: "abc123 Initial Commit, First Deploy"
    commit id: "ghi789 docs: fix typo in documentation"
  

For you (and future you), nothing has changed apart from commit message becaue history looks similar. What really changes with your message is commit hash. First it was def456, now it’s ghi789 which means Git creates commit object everytime you edit history.

If you need to add or edit files instead, you will follow:

git add modified_files

If you want to keep same commit message:

git commit --amend --no-edit

If you need to update commit message too, then:

git commit --amend -m 'more meaningful message'

Important

Updating commits for local repository is generally safe. But, it requires caution while you update commits for shared or remote repositories. This can lead of confusion.

Edit Commits In Scale With Rebase

Amending one or two commits is fine with git commit --amend but if you require doing it at scale then you need rebasing. When you start interactive rebasing git rebase -i <base_commit>, you typically have two options of editing commits:

CommandWhat it does
rewordKeep the commit’s changes, but let you edit its message
editPause at this commit so you can amend it (add changes, split it, etc.)

reword is for editing commits and edit is for adding and amending changes.

Setup: Before Rebase

Let’s setup for this exercise:

mkdir editing-commits
cd editing-commits
git init
echo 'print("Hello")' > file; git add file; git commit -m "Initial Commit"
echo 'print("Hi")' > file; git add file; git commit -m "greet Hi not Hello"
echo 'print(open("greet").read())' > file; git add file; git commit -m "feat: greet from greet file"
echo 'print(open("greet").read(), end="!")' > file; git add file; git commit -m "style: add ! after greet"

Your commit history here:

    gitGraph
    commit id:"4b77f4e Initial Commit"
    commit id:"d5ba983 greet Hi not Hello"
    commit id:"0c207d8 feat: greet from greet file"
    commit id:"e1ae2eb style: add ! after greet"
  

You can view history with:

git log --oneline

And this will show:

e1ae2eb (HEAD -> master) style: add ! after greet
0c207d8 feat: greet from greet file
d5ba983 greet Hi not Hello
4b77f4e Initial Commit

Editing Process

First of all, you realize that:

  • Commit d5ba983 doesn’t matches conventional commit message fomat
  • You add feature to read greet from greet file but greet file was not added (commit 0c207d8)

It means you have to:

  • Update commit message for d5ba983 (apply reword)
  • Add new file greet for 0c207d8 (apply edit)

Since d5ba983 is the oldest command we want in our rebase process we will choose it’s parent as base to start rebasing. Seeing commit logs, we know that 4b77f4e is it’s parent but is it safe to use ^ symbol. So for d5ba983, parent is d5ba983^:

git rebase -i d5ba983^

Important

Your commit hash will differ. See your own commit history and apply the correct hash.

Git will start rebasing process and open todo list in default editor:

pick d5ba983 greet Hi not Hello
pick 0c207d8 feat: greet from greet file
pick e1ae2eb style: add ! after greet

As discussed before, choose reword for d5ba983 and edit for 0c207d8:

reword d5ba983 greet Hi not Hello
edit 0c207d8 feat: greet from greet file
pick e1ae2eb style: add ! after greet

Now the commands are the same as we want. Save and Close the file so that Git can continue.

Since reword is the first command, Git immediately opens new text editor to edit your commit message which will currently contain your original commit message:

greet Hi not Hello

Our idea was to match conventional commit, so use commit type refactor:

refactor: greet Hi not Hello

Save and Close the file to apply changes. Perfect, Git has reword for commit message. But now you see a long output:

[detached HEAD b9a4d08] refactor: greet Hi not Hello
 Date: Fri Aug 7 00:47:35 2026 +0545
 1 file changed, 1 insertion(+), 1 deletion(-)
Stopped at 0c207d8...  feat: greet from greet file
You can amend the commit now, with

  git commit --amend

Once you are satisfied with your changes, run

  git rebase --continue

This is because the next instruction was to edit 0c207d8. Git stops here so that we can add greet file as we have planned. So add greet and amend the commit.

echo "Radhe Radhe" > greet
git add greet
git commit --amend --no-edit

Note

Use --no-edit only if you are satisfied with the old commit message. Even though we added greet, for me, feat: greet from greet file is still fine message.

You will see the output:

[detached HEAD 5fea5e0] feat: greet from greet file
 Date: Fri Aug 7 00:47:35 2026 +0545
 2 files changed, 2 insertions(+), 1 deletion(-)
 create mode 100644 greet

Once your are statisfied with this, you continue rebase:

git rebase --continue

Git applies the third command pick from the list. Since, it doesn’t encounter any conflicts while picking e1ae2eb, The rebase process is completed.

Successfully rebased and updated refs/heads/master.

After Rebase

You can view the commit history:

9182460 (HEAD -> master) style: add ! after greet
5fea5e0 feat: greet from greet file
b9a4d08 refactor: greet Hi not Hello
4b77f4e Initial Commit
    gitGraph
    commit id:"4b77f4e Initial Commit"
    commit id:"b9a4d08 refactor: greet Hi not Hello"
    commit id:"5fea5e0 feat: greet from greet file"
    commit id:"9182460 style: add ! after greet"
  

If you see the logs before rebase, only the commit hash of Initial commit 4b77f4e is unchanged. We have already talked that rebasing alters history — this should not confuse you anymore.

Commit history after rebase alrady shows commit message is changed (the refactor: greet... one).

Can you show me the proof greet was added too?

Yes, if fact it’s already in you disk. Just do ls and you get:

file  greet

But there’s more. From our discussion, we know:

5fea5e0 feat: greet from greet file

greet should exist from here on. So first let’s try from it’s parent (b9a4d08) to show greet does not exist yet:

git show b9a4d08:greet

Git says:

fatal: path 'greet' exists on disk, but not in 'b9a4d08'

I already told it’s already on the disk. So, proof that greet exists after 5fea5e0:

git show 5fea5e0:greet

Git will give you greet’s contents:

Radhe Radhe

Best Practices and Nuances

  • Edit commits locally with confidence: Rewriting commits is generally safe when working only on your local branch and no one else has based work on those commits.

  • Be careful after pushing: If the commits have already been pushed to a shared remote branch, editing them rewrites history and typically requires a force push (git push --force-with-lease is safer than --force).

  • Choose the right tool: Use git commit --amend for the latest commit, git rebase -i when you need to edit, reorder, squash, or split multiple commits.

  • Preserve a clean, meaningful history: Before rewriting, make a backup branch if the changes are significant, and avoid rewriting shared branches unless everyone involved understands the impact.

Last updated on