Rebase is a Git operation that integrates changes from one branch into another by replaying commits onto a new base commit. Instead of merging with a dedicated merge commit, it rewrites the commit history to produce a linear sequence. This approach creates a cleaner project history but requires disciplined usage to avoid collaboration issues.
How It Works
When you run a rebase, Git identifies the common ancestor between the current branch and the target branch. It then temporarily removes your branch’s unique commits, updates the branch pointer to the latest commit of the target branch, and reapplies your commits one by one on top of it.
Each commit is rewritten with a new commit hash because its parent changes. From Git’s perspective, these are new commits, even if the content remains similar. If conflicts occur during replay, Git pauses the process and prompts you to resolve them before continuing.
Interactive mode (git rebase -i) adds more control. Engineers can reorder, squash, edit, or drop commits before integrating them. This is commonly used to clean up noisy commit histories before merging into a shared branch such as main. However, rewriting history on branches already pushed to shared repositories can disrupt collaborators, since their local history no longer matches the rewritten branch.
Why It Matters
Linear history simplifies code reviews, incident investigations, and root cause analysis. For SRE and platform teams operating high-change repositories, a clean commit graph reduces cognitive load and accelerates debugging. It also improves traceability in CI/CD pipelines where bisecting failures depends on clear commit progression.
However, misuse can cause force-pushes and history divergence, which disrupt automation and team workflows. Teams must define policies for when history rewriting is acceptable, typically restricting it to feature branches.
Key Takeaway
Rebase keeps commit history linear and readable, but rewriting history demands strict coordination and disciplined workflow practices.