Preserve Branch Topology or Linearize Shared Feature History

Answer

For a feature branch that has already been pushed to a shared remote, the documented trade‑off that should govern the choice is the presence of downstream work: merge when other developers have based commits on the branch (to preserve commit IDs), and rebase only when the branch is isolated and the team agrees to a force‑push.

Confirmed Facts

• Git does not provide any configuration that automatically selects merge or rebase based on remote‑tracking state; settings like pull.rebase affect only the pull operation, not manual integration of an already‑shared branch.
• A merge preserves the exact divergence points and original commit SHA‑1s, adding a merge commit that can clutter the graph.
• A rebase rewrites commit IDs to produce a linear history, which simplifies later inspection but requires a force‑push and can break any local copies that depend on the old IDs.
• If other developers have already created work that is based on the feature branch commits, rebasing will invalidate those base points, causing merge conflicts or broken references when they try to re‑base or pull.

Likely Explanation

The primary reason to prefer a merge for a shared branch is safety: it keeps the history that others may have relied on unchanged. Rebasing is only safe when you can guarantee that no one else has built on the branch, because the rewrite of commit hashes would otherwise force collaborators to re‑fetch and re‑base their work, which is disruptive and error‑prone.

Steps for This Case

1. Fetch the latest remote state:

   git fetch origin

2. Determine whether any other branches or commits are based on the feature branch. A quick way is to list all remote branches that contain the feature tip:

   git branch -r --contains origin/feature‑branch

   If the list shows only the feature branch itself, there is no known downstream work.
3. If downstream work exists (or you cannot confirm its absence), perform a merge:

   git checkout main
   git merge --no-ff origin/feature‑branch
   git push

4. If no downstream work is found and the team agrees to rewrite history, rebase and force‑push:

   git checkout feature‑branch
   git rebase origin/main
   git push --force-with-lease origin feature‑branch

5. After integration, verify the graph:

   git log --graph --oneline --decorate

   to see whether a merge commit or a linear history resulted.

Missing Diagnostic Detail

The recommendation changes if you cannot confirm whether any other developer has based work on the feature branch. Before deciding to rebase, you should ask: Have any other developers created branches or commits that are reachable from the feature branch tip? If the answer is yes or unknown, choose a merge; if the answer is definitively no, a rebase is acceptable.