In Git, what is the difference between merging main into your branch and rebasing onto it?

## Two ways to catch up with a moving trunk You branched off `main` a week ago. `main` has moved on. You need your work to sit on top of that new work before it can land. Git offers two mechanisms with genuinely different semantics. ## Merge: join the histories `git merge main` (while your branch is checked out) computes the merge base — the last commit both branches share — and produces a three-way merge of the two tips. The result is recorded as a **merge commit** with two parents. Crucially, none of your existing commits are altered: their hashes, their contents and their parent links all stay exactly as they were. The history is now a graph with a visible join. Properties worth naming: - Nothing is rewritten, so a branch you have already pushed can be updated with an ordinary push, and teammates who have your branch just fast-forward. - Conflicts are resolved **once**, against the combined state of both tips. - The graph records the true shape of what happened, including the fact that you worked in parallel. - Repeated over many branches, the graph becomes hard to read, and a `git log` without a graph flag interleaves commits from many lines of work. ## Rebase: re-create the commits elsewhere `git rebase main` takes the commits that are on your branch but not on `main` and replays them, in order, on top of `main`'s current tip. Each replay is effectively a cherry-pick: apply that commit's change to the new base and record a new commit. Because a commit's identity is derived from its full content — including its parent and its committer metadata — every replayed commit gets a **new hash**. The originals are not modified; they are simply no longer on the branch, and remain reachable through the reflog until garbage collection. Properties worth naming: - The history is linear. `git log` reads as a sequence, and the branch looks as though it was written against today's `main`. - Conflicts can occur **per replayed commit**, so a ten-commit branch can stop ten times. - Because the commits are new objects, a branch you had already pushed no longer fast-forwards; updating the remote requires a force-push, and anyone who had the old commits must reconcile. - Intermediate commits in the rebased branch are new combinations that never existed before and were never built or tested in that form. ## The rule that follows The long-standing guidance — do not rebase commits that other people have already based work on — is a direct consequence of the copy semantics, not a stylistic preference. Rebasing your own unpushed or personally-owned branch costs nobody anything. Rebasing a branch two colleagues have pulled hands them a divergence they did not ask for. ## Choosing in practice A common, defensible split: rebase your own topic branch while it is in progress, to keep it current and readable; merge when integrating finished work, or whenever the branch is shared. Some teams go further in either direction, and the honest interview answer acknowledges that both are legitimate and the choice depends on how much the team values a linear log versus a never-rewritten record. ## What interviewers listen for A weak answer describes the two commands as different ways to get the same result, or reduces the difference to "rebase is cleaner". A strong answer says: merge creates a commit and preserves history; rebase creates *new copies* of your commits and discards the old ones from the branch; and everything else — the force-push, the per-commit conflicts, the danger on shared branches — follows mechanically from that one fact. Being able to derive the consequences instead of listing memorised pros and cons is the whole signal.