Git: amending, rebasing, and force pushing

Most beginner workflows do not need history rewriting immediately.

But once normal commits and branches make sense, three related ideas become worth understanding:

• amending a commit
• rebasing a branch
• force pushing rewritten history

git commit --amend replaces the most recent commit

If you want to change the last commit, Git provides:

git commit --amend

This does not edit the old commit in place. It creates a new commit that replaces the previous one.

That means the commit gets a new identity in Git history.

Why someone uses --amend

Common reasons include:

• fixing the most recent commit message
• adding a file that should have been in the last commit
• removing or adjusting the staged snapshot before sharing it

Examples:

git commit --amend -m "fix: correct button disabled state"
git add README.md
git commit --amend --no-edit

In the second example, --no-edit keeps the existing commit message while replacing the commit contents with the newly staged version.

Why --amend matters for shared history

Because --amend replaces a commit, it rewrites history.

If that commit only exists locally, this is usually straightforward.

If that commit was already pushed to a remote branch, your local branch history now differs from the remote branch history.

That is where force pushing enters the picture.

What rebasing is

Rebasing is another way to rewrite history.

At a high level, git rebase takes commits from one branch and reapplies them on top of a different base.

A common example:

git switch feature-branch
git rebase main

In practical terms, this says:

take the commits unique to feature-branch and replay them on top of the current main

That can make history look cleaner, but it also means the rewritten commits get new identities.

Why rebasing changes what push will do

If you rebase a branch that was already pushed, the remote branch still points to the old commits.

Your local branch now points to rewritten commits.

A normal push is often rejected because Git sees that the remote history would be replaced rather than simply extended.

Force pushing updates the remote branch with rewritten history

After rewriting history with --amend or git rebase, you may need to force push.

The command you may eventually need is:

git push --force-with-lease

This updates the remote branch to match your rewritten local branch.

Why --force-with-lease is safer than --force

There are two important force-push styles:

git push --force
git push --force-with-lease

--force tells Git to overwrite the remote branch regardless.

--force-with-lease is safer because it checks that the remote branch is still in the state you expect before replacing it.

That reduces the risk of overwriting someone else’s newer remote work by mistake.

A safe beginner rule

Use normal commits and merges as the default.

Use --amend when:

• the commit is still local
• you are cleaning up the most recent commit

Use rebase when:

• you understand that it rewrites commits
• the branch is still private, or the team explicitly expects that workflow

Be more cautious when the branch is already shared with others.