Merge

Merge combines histories. A **fast-forward** moves the branch pointer when no divergent commits exist. A **merge commit** has two parents and records that two lines of work were integrated.

					git switch main
git merge feature/login        # may create merge commit or FF
git merge --no-ff release-2.1  # always record integration point
				

Merge preserves topology — useful for release branches, audit trails, and understanding when parallel work landed. Textual conflict markers (`<<<<<<<`) mean Git could not auto-combine; semantic correctness still needs tests.

On interviews: compare merge vs rebase, fast-forward vs merge commit, conflict resolution flow, and when preserving branch shape matters.

Common pitfalls: a clean textual merge that is semantically wrong; merging without updating the integration branch first; huge merges that bypass review.

The trade-off is explicit integration history (merge commits) versus linear readability (rebase on private branches).

Checklist:

• Know fast-forward versus merge commit semantics.
• Resolve conflicts with both branches' intent in mind.
• Run tests after integration.
• Prefer small merges reviewed in pull requests.