Git (version control) 2026-11-05
Git is a distributed version control system whose history records version-control snapshots linked by version-control commits. A local repository can contain history and support comparisons and new version-control commits without a connection to a central server. Version-control branches name movable tips of that history.[ref]
Suppose two collaborators start at the same version-control commit and each records a different change. Their new version-control commits share a parent in the commit graph. Exchanging repository objects makes both histories available; version-control merging can then combine their work, possibly exposing a merge conflict. The stored version-control snapshot identifies recorded file contents, while external datasets and installed software dependencies still need their own reproducibility record.
Merge conflict 2026-11-05
A merge conflict occurs when a version-control merging operation cannot automatically reconcile changes under its merge rules. For a typical three-way merge, the tool compares two revisions with their common base. Incompatible edits to the same region, or deletion on one side and modification on the other, can require a human decision.[ref]
For example, the base contains threshold=5; one side changes it to 7 and the other to 9. Choosing either value or a new value requires understanding the intended behavior. After editing the combined result, the resolver records that decision in version control. A textually conflict-free merge can still break a function's contract, so successful automatic combination supplies weaker evidence than software testing of the integrated program.
Version-control merging 2026-11-05
Version-control merging combines development histories and their changes into a result intended to preserve both lines of work. In Git, a usual three-way merge compares two branch tips with a common base. Independent edits may combine automatically; overlapping or incompatible edits can produce a merge conflict requiring a decision.[ref]
If one tip is already an ancestor of the other, a fast-forward can move the branch reference without creating a separate merge commit. Otherwise a merge commit can record the combined snapshot and both parents. A textually clean merge can still be semantically wrong: one 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.