= Version-control merging
<Version-control merging> combines development histories and their changes into a result intended to preserve both lines of work. In <Git (version control)>, a usual three-way merge compares two <version-control branch>[branch] tips with a common base. Independent edits may combine automatically; overlapping or incompatible edits can produce a <merge conflict> requiring a decision.<git-merge in the Git documentation>[Description, True merge and How conflicts are presented]{ref}
If one tip is already an ancestor of the other, a fast-forward can move the <version-control branch>[branch] reference without creating a separate merge <version-control commit>[commit]. Otherwise a merge <version-control commit>[commit] can record the combined <version-control snapshot>[snapshot] and both parents. A textually clean merge can still be semantically wrong: one <version-control branch>[branch] can change a <function>'s contract while another adds a caller using the old contract. Testing and review of the combined result remain distinct from resolving text conflicts.
Back to article page
