Branches, Fast-Forward and Three-Way Merges, and Branching Strategies: Configuration, Design Choices, and Tradeoffs

1. Branch mechanics are local; branching strategy is governance

Git core gives you refs, commits, merge bases, fast-forward rules, merge commits, squash mode, and rebase machinery. A team decides which of those shapes is acceptable for each integration path. Hosting products can then enforce server-side controls such as protected branches, required review, and merge queues; those are not local branch objects.

2. merge.ff controls ordinary merge behavior

git config --show-origin --show-scope --get merge.ff
git config --local merge.ff only

Current Git supports three practical modes: the normal fast-forward-when-possible behavior, false (equivalent to --no-ff for ordinary merges), and only (equivalent to --ff-only). A global setting can surprise repositories whose policy expects a different graph shape, so shared workflow rules should be explicit in documentation/automation rather than depending on an invisible developer default.

3. pull.ff belongs to pull/integration policy

git pull fetches and then integrates. pull.ff controls fast-forward behavior during that integration and can override merge.ff for pull. A team that wants pull never to create an accidental merge commit can choose pull.ff=only; a team using rebase on pull needs to define that separately.

git config --show-origin --show-scope --get pull.ff
git config --show-origin --show-scope --get pull.rebase

Chapter 07 teaches fetch/pull/remotes deeply. Here the key lesson is that a “surprise merge from pull” is often a configuration/policy issue, not mysterious Git behavior.

4. branch.<name>.mergeOptions can hide defaults in one branch

git config --local branch.trunk.mergeOptions --ff-only
git config --show-origin --show-scope --get branch.trunk.mergeOptions

This can make merges into a particular branch inherit options. It is powerful but easy to forget. Prefer obvious CI/runbook commands for critical integration constraints when hidden local configuration would make another clone behave differently.

5. Branch naming and lifecycle are discoverability policies

Names should tell humans what a ref represents without pretending the name supplies authorization. A small team might use feature/<topic>, fix/<incident>, and release/<line>. Lifecycle rules matter more than punctuation: who creates it, expected lifetime, integration target, who may delete it, and whether CI must pass before integration.

6. Protected integration is server-side, not a special Git branch type

A local trunk branch is structurally the same kind of ref as any other local branch. A hosting service may reject pushes, require reviews, require CI, or serialize merges. Those controls live at the remote service boundary and will be revisited in platform-specific courses. Local labs can still model the underlying ancestry and merge shape without an account.

7. Merge commit, squash, and rebased linear history answer different history-design questions

git merge --squash topic updates the working tree/index with the merge result but does not create a merge commit or record the topic as a merge parent; a subsequent normal commit creates one new single-parent commit. Rebase is covered deeply in Chapter 09 and should be limited to unpublished/local work unless a coordinated policy says otherwise.

8. Long-lived branches increase integration cost nonlinearly

The longer two branches evolve independently, the more code, configuration, tests, infrastructure assumptions, and deployment behavior can diverge. Even when Git reports no textual conflict, the combined result can be semantically wrong. Long-lived branches are justified when support/release constraints outweigh that integration cost—not because a diagram looks professional.

9. Decision table for common team constraints

10. Worked scenario — a six-person DevOps product team

The team deploys daily, supports only the currently deployed major version, requires review plus CI, and can hide incomplete features behind flags. A reasonable policy is: trunk is always releasable; feature/fix branches should normally live hours to a few days; integration is controlled on the server; hotfixes branch only long enough for review/validation; release branches are created only if a future support requirement appears.

That policy is maintainable because it follows the delivery model. Adopting permanent develop, release, and hotfix lanes without a matching support problem would increase operational cost without adding capability.

11. Knowledge check

12. Summary

Fast-forward and pull settings are policy levers, not universal best practices. Hidden global defaults can make clones behave differently. Merge, squash, and rebase shapes preserve different information, and branch lifetime should be chosen from deployment/support constraints rather than fashion.

Authoritative references

• git-config
• git-merge
• git-pull
• git-branch