Using git rebase to Keep Commit History Clean and Readable

The author introduces git rebase as a tool to make commit history clearer and more readable, explaining that rebase (变基) functions similarly to merge by integrating changes from one branch into another.

Through a visual example, the article shows the commit history before and after a rebase operation, using a master branch and a feature/1 branch that diverge after an initial commit ( add readme ). The master branch adds 3.js and 4.js , while feature/1 adds 1.js and 2.js .

After checking out feature/1 and running git rebase master , the commit log shows that the changes from master are applied first, followed by the feature commits, resulting in a linear, non‑forked history.

If conflicts arise during rebase, the article advises resolving them manually and then continuing with git add and git rebase --continue . To skip a problematic commit, use git rebase --skip .

The differences between git merge and git rebase are highlighted: a non‑fast‑forward merge creates an extra merge commit (e.g., Merge branch 'xxx' into 'xxx' ), while rebase rewrites history without such a merge commit. Merge typically requires resolving conflicts only once, whereas rebase may require repeated conflict resolution.

The article then covers the interactive rebase mode, useful for squashing multiple ineffective commits into a single clean commit. The command git rebase -i <base-commit> opens a Vim interface where the user can change pick to squash (or s ) for the desired commits, edit the combined commit message, and finish with :wq . An example shows compressing several commits into one, resulting in a tidy history.

Finally, a caution is given: interactive rebase should only be performed on personal feature branches, not on integration branches, to avoid rewriting shared history.