git branch flow
Out of the wide range of ways different teams use git branches, we're using a straightforward approach.
For most work, make a task-specific "feature branch" or "bugfix branch", make a series of edits and commits, merge in changes from master, then merge the result back to master, ideally using a Pull Request:
There will be many such feature branches in progress at a time.
Sometimes it makes sense to continue adding to the feature branch after the Pull Request, but it's useful to delete the branch when you stop working on it to reduce the number of stale branches.
A "development branch" is a term for a feature branch that may be shared by multiple developers and may hold a larger set of changes being staged for merging into master.
A "release branch" is used to prepare and make a public release. After branching it from "master", you might merge in select bug fixes. After making the release, you might cherry-pick a specific bug fix to make a bug-fix release.
This diagram also shows a tag on each release.
See this note in Issue #112, Removing my stale branches about tagging and deleting stale branches. One can always go back to a tag (or any findable git commit) and make a branch from there if needed.