development: although not included in the screenshots, this could be a valuable branch where developers can test their code together

feature branches: these branches are named after their feature and are branches private to the teams working on a feature.
When done with the feature this branch will merge in a target branch (development or acceptance), fix eventual merge conflicts and test. Then after checking out the target branch we’ll merge in this feature. During this merge period, the target branch should not be touched and should be protected by whoever has the Git Master role.

Our workflow for individual (solo) assignments is pretty linear.
I encourage branching for features of the assignments and rapid merging (two stages, as a students can get feedback from peers, TA or Instructor). As they test or demo their work (prior to the deadline) they might need to fix an issue, in which case the create a fix branch, which they merge once the issue is fixed.
They work on multiple features in the assignment, when the last one is finished and merged in dev without issues, then they merge to master.

The purpose of this module thus far seems to be to indicate to new faculty that GitHub Classroom often fails to create new repos and import starter code. Unfortunately, this tends to happen at the worst time, such as a live coding lab. I’ll try again some other day.