The last few articles set up the folder structure that scales for a full stack SaaS: where the frontend and backend live, how a monorepo shares types, where config sits. None of that matters much if the team can't move code through Git without stepping on each other. This is the last piece of Module 1 in the Full Stack SaaS Masterclass, the series that started with choosing the stack and has been building the foundation ever since.
Git workflow is one of those topics every team has an opinion on, usually inherited from wherever they worked last. Some of those opinions come from companies with fifty engineers and three release trains a day. Applying that process to a team of two or three people building a SaaS product is a good way to spend more time managing branches than writing features.
I've settled on a workflow that's boring on purpose. It borrows the useful parts of GitFlow and trunk-based development, drops the ceremony neither needs, and scales down cleanly to a solo founder and up reasonably far before it needs to change.
Trunk-based, not GitFlow
GitFlow gives you develop, release/*, hotfix/*, and long-lived feature branches that merge back through a maze of rules. It was designed for teams shipping infrequently, with formal release cycles and multiple versions in production at once. A SaaS with one production environment and continuous deploys doesn't have that problem, so most of GitFlow's structure is solving something you don't have.
