Using git rebase to Keep Commit History Clean: A Practical Guide

1) git rebase makes your commit history clearer and more readable

git rebase is used to integrate changes from one branch onto another, similar to git merge but rewriting history to appear linear.

In the example, two branches master and feature/1 start from an initial commit add readme . The master branch adds 3.js and 4.js with two commits, while feature/1 adds 1.js and 2.js with its own two commits.

After checking out feature/1 , running git rebase master reapplies the feature commits on top of the latest master commit, resulting in a linear history without a merge node.

If conflicts occur during rebase, resolve them manually, then continue with git add and git rebase --continue . To skip a problematic commit, use git rebase --skip .

2) Difference between git merge and git rebase

git merge creates an additional merge commit when a fast‑forward is not possible, preserving the original branch structure, whereas git rebase rewrites history to appear as a straight line.

When resolving conflicts, merge requires a single conflict resolution, while rebase may require resolving conflicts repeatedly for each rebased commit.

3) git rebase interactive mode

Interactive rebase ( git rebase -i <base‑commit> ) lets you squash multiple commits into one, edit messages, or reorder commits. For example, to squash all commits before ac18084 :

git rebase -i ac18084

The editor opens with a list of commits prefixed by commands like pick or s (squash). Change the commands as needed, save and quit (e.g., :wq ), then edit the combined commit message and finalize.

Note: Interactive rebase should only be performed on private feature branches, not on shared integration branches, to avoid rewriting shared history.