git rebase Tutorial

The short version

git rebase reapplies a set of commits onto a new base, so you often end up with similar content but different commit IDs.

It helps to think of rebase as “re-queueing your work.” The key visual signal is that E/F become E'/F', which is exactly why rebase is considered history rewriting.

When it is a good fit

• Bring a feature branch up to date with main
• Clean up commit history before merging
• Reorder, squash, or rewrite commits with interactive rebase

Basic workflow

git checkout feature/login
git fetch origin
git rebase origin/main

Handling conflicts

git status
# resolve conflicts manually
git add <resolved-files>
git rebase --continue

Abort if needed:

git rebase --abort

A safer real-world workflow

When you want to clean up a local feature branch, a safer sequence is usually:

1. run git status and confirm the working tree is clean
2. run git fetch origin
3. create a backup branch if the rewrite is risky
4. run git rebase origin/main
5. review the result with git log --oneline --graph

For example:

git branch backup/feature-login-before-rebase

Why interactive rebase matters

git rebase -i HEAD~4

Interactive rebase is useful for:

• squashing noisy commits
• reordering history for readability
• rewriting commit messages
• dropping experimental commits

The most common actions are still just:

• pick
• reword
• squash
• fixup
• drop

For most teams, turning a messy branch into a few clearer logical commits already delivers most of the value.

pull --rebase versus fetch-then-rebase

Fetch-then-rebase is still easier to reason about because it separates:

1. learning upstream state
2. choosing to rewrite local history
3. recovering when something goes wrong

Using the picture as a decision aid

If your situation looks like “my own feature branch is behind main, and these commits have not been shared yet,” the rebase model above is usually a good fit.

If what you really mean is “this branch is already part of review, CI, or someone else’s work,” then the safer question is no longer “can I make the history cleaner,” but “can I still rewrite it safely.”

Additional caution

Rebase is not automatically safe just because the branch is “yours.” If CI, review flows, or teammates already rely on that branch, rewriting it can still create coordination cost.

Recovery mindset

If the result looks wrong, use reflog first. A conservative recovery path is:

git checkout -b rescue/rebase HEAD@{1}

Anchor the old position before deciding whether to reset or replay work again.

What problem this command solves in a workflow

git rebase directly affects history shape, ref position, or relationships between commits. The first decision is whether you are organizing private local history or touching history that is already shared with others.

Typical use cases

• Use git rebase when integrating branches, undoing changes, selecting commits, or reshaping a sequence of commits.
• Put git rebase inside a “backup first, mutate second, verify last” flow so higher-risk history operations stay recoverable.
• Use git rebase to understand ancestry, recovery paths, and commit causality during conflict resolution or post-incident analysis.

Diagram view

Special cases and boundaries

• The most expensive failure mode in history commands is rewriting or moving commits that other people already depend on.
• If the operation might affect team flow, run git status, git log --oneline --graph, and git reflog first so the recovery path is visible.
• When in doubt, create a backup branch before continuing so you preserve an obvious way back.
• If the branch is already under review, CI, or someone else has based work on it, stop and check whether rewriting it is still safe.

Try it yourself

git switch -c lab/rebase-demo
# make two commits
# switch to main and add one more commit