For my senior design team of 5 developers using Scrum and JIRA: master ("production") branch: - this is deployed - nobody (not even GitHub Org administrators

For my senior design team of 5 developers using Scrum and JIRA: master ("production") branch: - this is deployed - nobody (not even GitHub Org administrators) can push; master is only changed via approved PR dev branch: - the base "working" branch during each 3-week sprint - pushing is allowed iff the change is trivial or already has team consensus (e.g. changing linter rules) - this is where we demo to our Product Owner "story" branches: - branched from dev - named along the the lines of "alternate-checkout-TFF-75-story" - base branch for any work that needs to be done for a user story "task" branches: - branched from the corresponding story branch - (usually) named along the lines of "item-unavailable-TFF-92" For all branches: - CI must pass - all PRs require >= 2 approvals, unless it is a trivial change then only 1 - require PRs when merging upstream (i.e. task -> story -> dev -> master) - merge freely when going downstream (i.e. master -> dev -> story -> task) - do not merge from story-A to story-B nor task-A to task-B - squash commits when going task -> story and story -> dev - do not squash when going dev -> master Having stroy & task branches help keep the changes for each new feature in easily digestible chunks. The story branch is particularly helpful when two tasks need the same code, but the story, task-A, nor task-B branches are ready to go to dev. So we merge the shared code to the story branch, then the other task branch can merge down the required code from the story branch. Currently, there is some contention over our verbose branch naming scheme. Previously, when 3/5 of the team was working on a different project, the branch naming scheme was "name-of-story-TSS-XX-story" for stories and "name-of-story-TSS-XX/name-of-task-TSS-XX".