2024-01-14
Git branches as a social construct
Over on the Fediverse, I had a half-baked thesis:
A half-baked thesis: branches in Git are a social construct, somewhat enabled by technical features. We talk about things having been done on a branch or existing on a branch, or what branches are what on an intertwined tree of them, even when this is not something you can find in the Git repository.
(This is since commits aren't permanently associated with a branch; they are merely currently reachable from one or more branches. What branch a multi-head-reachable commit is on is up to us.)
The background on this is more or less Julia Evans' git branches: intuition & reality, or more exactly a Fediverse discussion between Julia Evans and Mark Dominus (and Mark Dominus's I wish people would stop insisting that Git branches are nothing but refs).
This ties into my long standing view that modern version control systems are a user interface to their underlying mathematics. Git has an internal, mathematical view of what 'branches' are, but very few people actually use this mathematical view; instead we use a variety of 'user interface' views of what branches are and how we think of them. Git supports these user views of branches with various 'porcelain' features.
Some projects using Git actively work to create branches that have a more concrete and durable existence. For instance, commits on a Go release branch have the branch name in the commit's title, which is something the Go project does for a lot of branches that are used in Go development and release. For development branches specifically, this durably marks commits as having been done on the branch even after the branch is merged to the 'main' development branch.
Certainly, how I normally think of Git branches is different from their technical existence, and it differs from branch to branch. For example, in a typical repository I think of the 'main' branch as running all the way back to the creation of the repository, but other branches as only running back to where they split from 'main', despite this not being technically correct.
(Another sign of Git branches as being a bit socially constructed is how you can rename them (per the comments).)
PS: There are other VCSes where branches have a more durable existence in the VCS history. These VCSes are neither wrong nor right; my view is that they've taken a different view of both the UI and the mathematics of what 'branches' are in their mathematical version of version control.