Design and implement a structure for the flow of work

GitHub Flow

A deliberately small branching model:

1. Create a branch from main.
2. Commit changes.
3. Open a pull request.
4. Review and discuss.
5. Merge.
6. Deploy — main is always deployable.

The defining constraint is that main is always deployable. Everything else follows: branches are short-lived because a long-lived branch drifts from a moving main, and releases are frequent because there is nothing to batch up.

When GitHub Flow is not enough

That last row is the important pairing. GitHub Flow assumes you can merge to main safely; feature flags are what make that true for work spanning several cycles, because the code ships dormant rather than living on a branch.

Work item linkage

The flow of work is not only branches. A change should be traceable from the item that requested it, through the commit and pull request, to the build and the deployment that shipped it. Establishing that chain is a design decision made at the start — retrofitting traceability across months of history is not practical.

Primary sources

• https://docs.github.com/en/get-started/using-github/github-flow
• https://learn.microsoft.com/en-us/azure/devops/boards/backlogs/link-work-items-support-traceability