Tangentially, I like to work with Gerrit [1], which approaches the core problem in a different way... "Stacked branches" seem to be a terminology which derives

Tangentially, I like to work with Gerrit [1], which approaches the core problem in a different way... "Stacked branches" seem to be a terminology which derives from Github/etc's approach to Pull Requests, where one PR maps to one atomic change. The PR can either be integrated in the repo as a merge, in which case you maintain the history of the PR and all its changes through its reviews, or as a squash-merge, in which case you flatten the PR's review history into one commit. But what if you want to maintain a series of separate but related commits? PRs don't really help you there, so people ended up inventing the concept of Stacked Branches, as discussed in the article. Gerrit took a different approach, and requires you to add metadata to each commit's message, the Change-Id. This way Gerrit can track your commit through its review evolution (since its SHA will change with each iteration). This also allows Gerrit to trivially track a series of related changes through their overall evolution, since it can use git's normal branch data to track commit's relation to each other, and the Change-Id to track one commit as it evolves. In any case, both solutions demonstrate that Git lacks a way to track the evolution of specific commits throughout their review history (a 2D branch in a way), so review tools like Github/etc and Gerrit had to create their own solution on top of it. [1] https://www.gerritcodereview.com/ https://www.gerritcodereview.com/