Git can rewrite history. That’s actually the point.

Rebase, interactive rebase, and cherry-pick -when and how to use them.

The first time someone tells you Git can rewrite history, it sounds dangerous. It isn’t -as long as you know one rule. Learn that rule first, and everything else in this article makes sense.

2 branch timelines side by side-one messy with merge commits, one clean after a rebase. Minimal, labeled, no decoration.

The golden rule

Never rebase commits that other people have already pulled.

That’s it. Rebase rewrites commits -it changes their hashes. If someone else built work on top of those commits, your rewrite breaks their history. Keep rebase to commits that only exist on your machine, or on a branch only you’re working on, and you’ll never cause a problem.

What rebase actually does

When you merge, Git creates a new “merge commit” that ties two branches together. The history stays exactly as it happened -messy bumps and all.

When you rebase, Git picks up your commits and replays them on top of another branch. No merge commit. The history reads like everything happened in a straight line.

git switch feature
git rebase main

This takes every commit on feature that isn't on main, and replays them on top of main's latest commit. Your branch stays current, your history stays clean.

Think of it as ironing out the wrinkles before you present your work.

When to use it -and when not to

Use rebase when:

• You want to bring your feature branch up to date with main before opening a pull request.
• You want a clean, linear history that’s easy to read later.

Don’t use rebase when:

• The branch is shared -anyone else has pulled it.
• You’re mid-conflict and not sure what you’re doing yet. Merge first, understand rebase second.

Handling conflicts during a rebase

Rebase replays commits one at a time. If a conflict appears, Git pauses and waits for you:

# Fix the conflict in your editor, then:
git add the-fixed-file.js
git rebase --continue

# Changed your mind? Back out completely:
git rebase --abort

--abort puts everything back exactly as it was before you started. No harm done.

Interactive rebase -rewriting your own history

This is where rebase gets powerful. Before you push, you can clean up your own commits -reorder them, reword them, combine them, drop the ones that shouldn’t exist.

git rebase -i HEAD~3   # look at the last 3 commits

Git opens an editor with your commits listed:

pick a3f9c12 Add login form
pick 8d2e901 Fix typo
pick 3c1a004 WIP dont push this

Change “pick“ to one of these:

Command                                Does what 

pick                                   Keep the commit as-is
reword                                 Keep it, but edit the message
edit                                   Pause here so you can amend the commit
drop                                   Delete the commit entirely
squash                                 Combine with the commit above it

Save and close -Git does the rest. That “WIP dont push this” commit disappears. The typo fix folds into the commit above it. Your history looks intentional.

git cherry-pick-take one commit, leave the rest

Sometimes you don’t want the whole branch. You just want one specific commit from it.

git cherry-pick a3f9c12

Git takes that commit and applies it to wherever you are now. Useful when a bug fix lives on a feature branch and you need it on main without merging everything else.

One last thing

AI can write a rebase command for you in seconds. It can explain the flags, generate the steps, even talk you through a conflict. But if you don’t know the golden rule-never rebase what others have pulled -no prompt will save you from the fallout.

That’s the pattern across all of Git: the tools get easier to reach. The judgment still has to be yours.