Master Git Rebase: Clean Up Commits and Streamline Branches

1. Origin

During a deployment the author noticed 62 separate commits and felt the need to clean up the commit history.

2. Problems Caused by Too Many Commits

Makes code review painful because a small feature is split into dozens of commits.

Pollutes the branch history, making rollbacks and hot‑fixes difficult.

3. Rebase Scenario 1 – Squashing Multiple Commits

To combine the last four commits into one: git rebase -i HEAD~4 The interactive editor opens with a list of commands:

p, pick – use commit

r, reword – edit commit message

e, edit – stop for amending

s, squash – meld into previous commit

f, fixup – squash but discard this commit's message

x, exec – run a shell command

d, drop – remove commit

Replace the first three lines with s (squash) and keep the last as p:

s cacc52da add: qrcode
s f072ef48 update: indexeddb hack
s 4e84901a feat: add indexedDB folder
p 8f33126c feat: add test2.js

If a "cannot 'squash' without a previous commit" error appears, ensure you are not squashing the first commit.

To exit the editor without saving, use: git rebase --edit-todo After editing, continue with: git rebase --continue Finally, view the cleaned history: git log The three original commits are now a single, tidy commit.

4. Rebase Scenario 2 – Branch Synchronization

Create a feature branch from master: git checkout -b feature1 After a teammate pushes a hotfix to master, merge it locally: git merge master To avoid a merge commit and keep a linear history, rebase the feature branch onto the updated master: git rebase master Rebase works by temporarily removing the feature commits, updating the branch to the latest master, then re‑applying the saved patches.

If conflicts arise, resolve them, stage the changes with git add, and continue: git rebase --continue At any point you can abort the rebase:

git rebase --abort

5. Additional Rebase Use Cases

Rebase an outdated feature branch onto the latest master before continuing development.

When resuming a long‑paused parallel work stream, rebase onto the current base to avoid divergence.

6. Why Rebase Can Be Dangerous

Rebasing rewrites commit history. If commits have already been pushed and shared, other developers may lose those commits when they pull, leading to inconsistencies. Only rebase branches that are private or not yet pushed.

Conclusion: As long as the commits you plan to rebase have not been pushed to a shared remote, using git rebase is safe.

7. References

rebase

git‑rebase usage summary

git rebase operations

git‑rebase vs git‑merge detailed comparison