Rebasing replays the commits from your branch onto the tip of another branch one by one, rewriting their hashes, so the resulting history looks as if you started your work from the latest commit on that base branch.
Key Points: • The result is a linear history without the extra merge commits that git merge produces when branches have diverged. • A clean, linear log is easier to read and makes git bisect far more effective when hunting for the commit that introduced a bug. • Rebasing rewrites commit hashes, so it should never be done on commits that have already been pushed and could be in use by others, unless the whole team agrees. • It's typically used to bring a feature branch up to date with main before opening or merging a pull request. • Merge remains the safer default for shared or public branches, since it never alters existing history.
Example: Before opening a pull request, a developer runs git rebase main on their feature branch so their commits appear to start from main's latest commit, giving reviewers a clean, linear diff instead of a tangled merge history.
Code Example:
git checkout feature-branch
git rebase mainInterview Tip: A concise interview answer is:
"Rebase replays your branch's commits on top of another branch's tip, producing a clean linear history instead of an extra merge commit. I use it to bring a feature branch up to date with main before merging, but never on commits that have already been pushed and shared."