What is git rebase
Last updated: April 1, 2026
Key Facts
- Git rebase rewrites commit history by moving commits to a new base, different from merge which creates a new merge commit
- The command is useful for cleaning up commit history before merging branches to main or master branch
- Interactive rebasing allows developers to modify, reorder, squash, or drop commits during the rebasing process
- Rebasing should be used carefully on public branches to avoid conflicts and confusion with other developers
- Common use case is rebasing feature branches onto the latest main branch to incorporate recent changes
Overview
Git rebase is a Git command that reapplies a series of commits from one branch on top of another branch. Unlike merging, which combines branch histories, rebasing replays your commits onto a different base, creating a linear and cleaner project history.
How Git Rebase Works
When you run git rebase, Git performs the following steps: First, it identifies the commits that exist in your current branch but not in the target branch. Second, it temporarily stores these commits. Third, it updates your current branch to match the target branch. Finally, it reapplies your stored commits on top of the new base, one by one. If conflicts occur during reapplication, you must resolve them before continuing.
Rebase vs. Merge
The key difference between rebase and merge lies in how they integrate changes. Merging creates a new merge commit that ties two branch histories together, resulting in a more complex, non-linear history. Rebasing rewrites history to maintain a straight, linear progression of commits. Rebase produces cleaner history but rewrites commits, while merge preserves the complete history of both branches.
Interactive Rebase
Interactive rebase (git rebase -i) allows you to modify commits during the rebasing process. You can reorder commits, squash multiple commits into one, edit commit messages, or drop commits entirely. This is particularly useful for cleaning up your commit history before submitting a pull request, consolidating multiple small fixes into logical commits, or removing accidentally committed sensitive information.
Best Practices and Cautions
Never rebase commits that have been pushed to public branches or shared repositories, as it rewrites history and causes conflicts for other developers. Only rebase local branches or feature branches that you haven't shared. Always communicate with team members before rebasing shared work. Use rebase for local cleanup and history improvement, but prefer merge for integrating changes in shared repositories to maintain a clear, preserved history.
Related Questions
When should I use rebase vs. merge?
Use rebase for local branches and to clean up history before merging. Use merge for integrating changes into shared branches or main branch to preserve complete history. Rebase is ideal for maintaining linear history on feature branches, while merge is safer for collaborative work.
What is interactive rebase?
Interactive rebase (<strong>git rebase -i</strong>) opens an editor where you can modify commits—reordering them, squashing multiple commits into one, editing messages, or removing commits. It's useful for cleaning up messy commit history and organizing changes logically before submitting pull requests.
What does 'git rebase --continue' do?
After resolving conflicts during a rebase, <strong>git rebase --continue</strong> tells Git to proceed with rebasing the next commit. You must stage your resolved files with <strong>git add</strong> before using this command. Use <strong>git rebase --abort</strong> if you want to cancel the rebase entirely.
More What Is in Daily Life
Also in Daily Life
More "What Is" Questions
Trending on WhatAnswers
Browse by Topic
Browse by Question Type
Sources
- Wikipedia - GitCC-BY-SA-4.0
- Git Documentation - RebasingCC-BY-SA-4.0