Git commits, branches and merging

What it means

A commit identifies a snapshot and links to its parent history. A branch is a movable reference to a commit, not an independent copy of the repository. The commit it currently names is its tip. To ask whether one commit is an ancestor of another, follow parent links backward from the later commit.

The example declares c1 → c2 → c3 and a separate c1 → feature path. Here the arrows run from earlier commits to their children: c2 has parent c1, c3 has parent c2, and feature has parent c1. The labels are synthetic commit identifiers, not real commit hashes. This small graph lets you distinguish including history by moving a reference from combining two lines of history.

Try it

Example: begin with Current branch tip = c1 and Commit to merge = c2. Change only Current branch tip to c2, then inspect the new result and explanation. Select Compare with baseline to display the baseline and current outcomes. These controls evaluate a local synthetic graph; they do not merge a repository.

Fast-forward is possible. The current tip is an ancestor of the target, so moving the reference can include the target history. A no-fast-forward policy may still request a merge commit.

Keep Commit to merge at c2. The declared graph stays c1 → c2 → c3 and c1 → feature; no file contents or merge-policy input changes.

Reset restores Current branch tip to c1 and Commit to merge to c2, removes input errors and clears the comparison. It leaves each FAQ answer and the About this model disclosure open or closed as you chose.

How it works

A merge starts with an ancestry question: does the current tip already include the target, or can the branch reach it by moving forward? Following parent links reveals which commits are already included.

The model applies these checks in order:

For a concrete divergence case, select Current branch tip = c2 and Commit to merge = feature. Both descend from c1, but c2 is not in feature's parent chain, and feature is not in c2's parent chain. A simple fast-forward therefore cannot combine them. A true merge can record the combined history in a merge commit; whether the file changes combine cleanly is a separate question that this model cannot answer.

This is why a fork in the graph is not a conflict detector. The graph describes relationships between commits. Conflict handling concerns how their content can be combined.

Worked example

This is a synthetic baseline, not a captured repository observation.

The result is Fast-forward is possible. The intermediate evidence is the parent relationship: c2 has parent c1. If the branch reference moved from c1 to c2, the old tip would remain reachable through c2's history, so no new merge commit is needed just to include that target history.

The example reports this possibility; it does not perform the branch move. It also does not decide whether your repository's integration policy calls for a merge commit instead.

What changes when the condition changes

Change Current branch tip from c1 to c2, keeping Commit to merge at c2. The result becomes Already up to date: the target is already reachable from the current branch tip; this merge need not move the branch.

The difference is not a new conflict or a change in file contents. Both selections now identify the same commit. The baseline allowed a move from c1 to c2; the contrast has already reached c2, so there is no further target history to include. The model handles this equality case before checking for a possible fast-forward.

In practice

Use this distinction first as a read-only inspection task. In a local repository you are authorized to inspect, identify the current branch and its tip, the intended target commit, the working-tree state and the graph connecting the tips. The expected observation is a definite pair of commit identities and enough parent history to classify their ancestry—not merely two familiar branch names.

STOP before any repository-changing operation if you cannot identify the intended target, find unexpected working-tree changes or lack enough history to establish the relationship. Leave the repository unchanged until that uncertainty is resolved. This page does not provide a merge, conflict-resolution or rollback procedure for a particular Git environment.

A fast-forward opportunity answers a history question, not whether you should integrate or publish. If an integration is later authorized and completed using an appropriate repository-specific procedure, inspect the resulting history and content, then run the relevant build and behavior checks. Neither a clean merge nor resolved conflicts establish application or deployment success.

Limits and unknowns

The example knows only the declared graph c1 → c2 → c3 and c1 → feature. It does not inspect your branch names, working tree, file contents, repository settings or permissions. No Git command, filesystem access, network request or repository change is performed.

Every supported pair has an ancestry answer within this graph, but actual content conflicts, applicable merge policy and application correctness remain unknown. A valid graph result is not a repository health check. If an input is invalid, no calculated outcome applies until you correct it or use Reset; a previous result must not be treated as the answer to that invalid input.

Without JavaScript, the initial example and explanatory text remain readable, but the interactive controls are unavailable. The static example is not a live repository check.

What to carry forward

Keep three decisions separate: ancestry tells you whether a branch can fast-forward, content determines whether integration needs conflict resolution, and application checks assess whether the result behaves as intended. Use the commit graph to choose the next question—not to declare a merge safe or a release ready.