Preserve Branch Topology or Linearize Shared Feature History

Goal

Choose between a merge commit and a rebase when integrating a feature branch into the main branch after the feature branch has already been pushed to a shared remote.

Constraint

Current Git versions document merge and rebase as workflow preferences and provide no automatic strategy selection. Merge preserves the exact divergence points but adds merge commits that can clutter the graph. Rebase rewrites commit identifiers to create a linear history, which can simplify later inspection but requires force pushes and can disrupt collaborators who have already checked out the branch.

Uncertainty

It is undocumented whether branch visibility alone should determine the strategy, or whether a team should standardize on one method regardless of whether the branch is public.

Which documented trade-off should govern the choice for an already-shared feature branch? Does Git offer any configuration that selects merge versus rebase automatically based on remote tracking state? How should the decision change if other developers have already based work on the branch commits?