Git Rebase: The Powerful Tool Developers Love—and Fear

What Is Rebase?

Rebase literally means “resetting the base”. It takes the commits on your current branch, removes them temporarily, and then re‑applies them on top of the latest target branch (e.g., main), creating new commits C' and D' that replace the originals.

main:    A → B → E → F
feature:          \→ C → D

After git rebase main the history becomes:

main:    A → B → E → F
feature:               \→ C' → D'

Rebase vs. Merge

Merge creates a new merge commit that preserves the exact branching structure, resulting in a graph with many merge nodes. Rebase produces a linear history by replaying commits, making the log easier to read.

Merge : keeps true branch history; suitable for integrating shared branches.

Rebase : creates a straight line; ideal for cleaning up personal feature branches.

Interactive Rebase : lets you edit, squash, or delete commits before pushing a PR.

Why Developers Like Rebase

It makes the commit history cleaner and more searchable, which simplifies code review, rollback, debugging, and project logs. For example, a series of noisy commits can be squashed into a few meaningful ones using git rebase -i HEAD~6:

feat(login): add sms login api
feat(login): add login page
test(login): add login tests

Why Developers Fear Rebase

Rebasing rewrites history. If you rebase a branch that has already been pushed and other teammates are working on it, a forced push can diverge their local history. git push --force The safer alternative is git push --force-with-lease, which only overwrites the remote if nobody else has added new commits.

Common Rebase Commands

git rebase main                     # move current commits onto latest main
git rebase origin/main               # rebase onto remote main
git rebase -i HEAD~3                 # interactive edit of last 3 commits
git rebase --continue                # resume after resolving conflicts
git rebase --abort                   # abort and return to original state
git rebase --skip                    # skip the current conflicted commit
git push --force-with-lease          # safe forced push after rebase

Handling Conflicts

During rebase, Git stops at the first conflicting commit. Resolve the conflict, stage the changes, and continue:

git add .
git rebase --continue

If the rebase becomes too messy, abort it:

git rebase --abort

When to Use Rebase

Synchronizing a personal feature branch with the latest main.

Cleaning up commits before opening a pull request.

Combining several small commits into logical units.

Amending recent commit messages.

Maintaining a linear project history.

Do not rebase public branches such as main, develop, or any shared remote branch unless you are certain no one else is based on them.

Recommended Workflow

git checkout main
git pull origin main

# create and work on a feature branch
git checkout -b feature/login
# ... develop and commit ...

git fetch origin
git rebase origin/main   # update with latest main, resolve conflicts if any

git add .
git rebase --continue

# before PR, clean up history
git rebase -i HEAD~3

git push origin feature/login
# if the branch was previously pushed and rebased, use safe force push
git push --force-with-lease

This flow is safe for personal branches; team policies may dictate whether the final integration uses merge, squash‑merge, or rebase.

Conclusion

Rebase is a powerful Git feature that, when used on local or personal branches, produces a clean, linear history and eases collaboration. However, rewriting history on shared branches can disrupt teammates, so always avoid rebasing public branches and prefer --force-with-lease when a forced push is unavoidable.