The following example code, QA and release management checklist assumes a git branching model like this:
master
branch is protected, and changes least frequently, only whendevelop
is merged into it.develop
branch is protected, and changes infrequently, and ideally only when feature and release branches off it are merged into it.- variously named release branches, branched off
develop
, finalized as various feature/fix branches off it are marged into it.- (optional, depending on number of developers on the release and need) variously named feature/fix branches off release branches, frequently made and merged into a release branch.
- variously named release branches, branched off
Also, a kanban or similar project management series of columns like the following may help track issues through the process. QA may move failed items back from "QA this" to "coding" to signal programmers that a fix or new feature failed (with detailed notes on the failure mode) :
`backlog | up next (or current sprint) | in progress | ready for QA | QA pa