Why Git history points backward
A Git commit is a record of a project’s state, along with information such as who made it and when. It also stores the identifier of its parent commit or commits. Because a commit refers to commits that already exist, history is built backward: newer work points toward the earlier work it came from.
That direction matters. A branch is not a separate copy of the project’s history; it is a movable reference to a commit. When you make another commit on the branch, Git adds a new node and moves the reference forward. The old commits remain available, preserving the route that led to the new state.
How two lines of work come together
Suppose two branches split from the same commit and then receive different changes. A merge can create a new commit with both branch tips as parents. That gives Git a record of both lines of development and a shared point from which they can be traced.
The merge does not reach back and alter the earlier commits. It adds a new commit that points to them. Since those parents already exist, the new connection runs toward the past rather than looping back to itself. That is why a merge can join histories without creating a cycle.
What the graph lets Git figure out
With history arranged this way, Git can follow parent links to determine which commits one branch contains and another does not. It can also find a common ancestor—the earlier commit from which two lines of work diverged—which helps it combine changes. The graph is not just a picture of project history; it is the structure Git uses to reason about how that history fits together.
