Difference between git merge and git rebase before a pull request

What's really being asked

This question checks if you know that git rebase is a history rewriting operation while git merge is a history preserving operation, and whether you can connect that distinction to real CI behavior. A senior candidate should not just recite definitions; they should explain the operational consequences for build traceability, artifact reproducibility, and team workflow.

The full answer

Four things in order. First, the mechanical difference: merge creates a merge commit that joins two histories, leaving original commit SHAs intact, whereas rebase replays commits from the feature branch onto the tip of the target branch, generating new SHAs and timestamps. Second, the history shape: merge produces a diamond or bubble graph that reflects true parallelism, while rebase yields a linear sequence that reads like a single timeline. Third, the CI impact: because rebase creates new SHAs, a pipeline that builds on every push will treat each rebased commit as a brand new artifact, burning compute minutes and breaking the one to one link between a commit and its test result; merge preserves SHAs so existing builds remain valid and the PR only triggers one integration build. Fourth, the social contract: rebase requires force pushing the rewritten branch, which can be dangerous on shared branches, while merge is non destructive.

The mistakes people make

Saying rebase is always better because it avoids merge commits. Another red flag is claiming that rebase preserves history; it does not, it rewrites it. A third is ignoring the CI side entirely and only talking about local aesthetics. Finally, stating that merge never creates conflicts while rebase does; both can conflict, the difference is when you resolve them.

Likely follow ups

The interviewer might ask how to handle a long lived feature branch with many commits, or when to use interactive rebase to squash. They may also ask about the golden rule of rebase: never rebase commits that have already been pushed to a shared branch. Another angle is signed commits: rebase invalidates GPG signatures because the commit content is rehashed.

A concrete example

Imagine a feature branch with five commits that is two days behind main. If you run git merge main, you create one merge commit, the five original SHAs stay the same, and CI builds that merge commit once for the pull request. If instead you run git rebase main, Git creates five new commits with fresh SHAs. Your CI system sees five new pushes, queues five builds, and the old build results for the original SHAs are orphaned. When a teammate asks why build 402 failed, the SHA in the log no longer exists on the branch, making debugging harder.