Four end-to-end scenarios — running an open-source project, shipping a web app, releasing a library, and recovering a broken repository — where the decisions and trade-offs matter more than any single feature.
4 topics
The earlier chapters introduced features one at a time. Real work never arrives that way — it arrives as a situation that forces you to choose among features under constraints, where the wrong default is convenient and the right one takes thought. These four case studies walk concrete scenarios from start to finish: a popular open-source repo, a web app's deploy pipeline, an automated library release, and a repository in three kinds of trouble at once.
The thread running through all four is judgment about trust and recovery. Which CI trigger can a stranger reach? Which credential can touch production, and for how long? Is the lost data still reachable, and what order do you act in? Each scenario ends with the specific mistakes that bite and the practices that prevent them, so the lesson transfers to the next situation you have not seen yet.
Four scenarios, four kinds of judgment
Open-source project
Strangers can open PRs. Pick triggers that keep secrets and production out of a fork's reach.
CI/CD for a web app
Gate the PR, build the image once, then promote that same digest from staging to prod.
Library auto-release
A tag triggers test, version, publish & sign — with provenance, no long-lived registry key.
Repository recovery
Lost work is usually still reachable. Use reflog and recovery in the right order before panic.