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.
Tip: It's useful to separate new feature changes from bug fix changes from code cleanup changes, but it's OK to do minor cleanup in the midst of a new feature or bug fix.
Here's a diagram from GitHub with a bit more detail on the elements of a Pull Request:
Note that when merging a Pull Request, GitHub has an option to squash all of its commits together when doing the merge. After merging, it has an option to delete the branch on GitHub. (You'll still have a local copy to delete.)
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.