Git Interview Question 5: Rebase Shared Branch
Git Interview Questions · Test 1 · question 5 of 10
The branch release/2.4 was pushed two weeks ago. Three teammates have since created their own branches from it and pushed commits to it. main now has several security fixes that also need to go into release/2.4.
A colleague suggests rebasing release/2.4 onto main. You want the fixes in release/2.4 without forcing your teammates to repair their local branches. What should you do?
Show answer and explanation
Answer:
A merge adds a new merge commit and leaves every existing commit on release/2.4 exactly as it was. Teammates who built on those commits just pull the merge commit as a normal fast-forward. Rebasing is different. It rewrites the branch's commits as new commits with new IDs. Pro Git states the rule plainly: do not rebase commits that exist outside your repository and that people may have based work on. Once rebased commits are pushed, anyone who built on the old ones has to reconcile duplicate history.
Option A breaks that rule. The rebase replaces commits your teammates already have, and the force push publishes the rewritten history. Every teammate's branch now diverges from the remote.
Option C is the same rewrite with a safer push. --force-with-lease refuses to overwrite commits you haven't seen. It doesn't stop the published commits from being replaced, so teammates who based work on them still have to untangle their branches.
Option D is worse. It points release/2.4 at main's tip, which drops every commit that exists only on the release branch and publishes that loss.
Reference: Pro Git: Rebasing