[fouric]

This seems like a reasonable take - there's only one problem: you haven't told us how to draw the rest of the owl.

How does one learn how to (1) think in this way (which necessitates not only abstract description but multiple concrete examples) and (2) what workflows and commands are necessary to effectively implement this?

[tonymet]

the team has 2 deliverables:

1. a ref (branch or tag) that builds (compiles & passes all tests including UAT)

2. every shared ref has a clean revision history that allows for graceful change management ( read changelog, fork, integrate, revert, A/B test)

Any ref shared by a team member (e.g. git push) must meet those two qualities. Team members must reconcile refs on their end (e.g. rebase) before they can submit a new ref meeting those expectations.

This way you are not prescribing a workflow (e.g. git-flow). The team needs to agree on that to their software delivery pipeline requirements.

In order to deliver these two expectations, they need to understand refs (pointers to a digraph) and how to manage them (rebase). tell them to RTFM the git manual on those topics.

Just like memory management, pointers, algos etc these skills are essential . They are not a "nice to have" to build software.