GitHub Flow doesn't support multiple versions being supported at once. A release occurs after every commit to the main branch. GitHub Flow is designed for use in environments that are practicing Continuous Delivery or Continuous Deployment, where the commit to the main branch triggers the deployment. If you are not deploying shortly after a commit to the main branch, then GitHub Flow isn't a good fit.
On the other hand, in Git Flow, deployments happen from release branches made off of the main branch. You can then keep the release branch around for patches for as long as the version exists in production, applying the patches to all of the supported versions, using either cherry-picking or manually depending on the state of the code for each version.
In GitHub Flow, there's no reason why a team of developers can't branch off the buggy version identified by a tag. However, since GitHub Flow is designed to support only one version in production, the buggy version would always be the current head of the main branch. The developers fixing the bug and the developers working on a new feature would both be branched off of the head of the main branch and, depending on who finished first, the other group would likely want to synchronize their branch with the updates committed to main.
It's also important to note that there are at least two versions of the GitHub Flow. In the original version, changes are merged to the main branch and the main branch is deployed shortly after each merge (which may result in two merges close together being deployed together). In the newer version, the feature branch is deployed and then merged into the main branch.
My personal preference is the first version, where the main branch is deployed to production. However, there is another question here on Software Engineering Stack Exchange as well as a GitHub blog post that go into details about how the newer version works for GitHub. It seems like they have infrastructure in place to ensure the safety of deployment from feature branches to production and prevent a feature branch that is missing commits from being deployed.
Thanks to TTT for finding some of this information and pointing it out in the comments.
current
, or name itmaster
if you prefer. (That just went full circle back to Git Flow.) That is the exact reasonmaster
exists in Git Flow, if you choose to use it.