I generally like GitHub Flow (https://guides.github.com/introduction/flow/) because it gives you isolation for individuals, but with only one ceremonial branch (ie. master). It might not be sufficient if you have formal release and QA cycles where you need to batch a bunch of changes to push to a staging environment, but all else being equal I prefer to optimize for branching, merging and deploying to production quickly. And with current cloud and/or containerized setups, it becomes possible to have on-demand staging environments (or even using ngrok with dev workstations!), but YMMV.
The main cherry I like to put on top is to always rebase before merging then merge with --no-ff (which is the default with GitHub PR merge button). This gives linear history for purposes of git bisect but preserves the topic branch structure so you don't have to read the tea leaves of the individual commits to piece together the overall development timeline. That one little piece goes a long way to addressing the concern that "rebasing destroys history" (which I don't agree with anyway, but that's the topic of another post).
This might not be worth it for certain types of contributors who are not programmers by trade, but for career programmers I believe mastering git and rebase in all its flavors (-i, --onto, pull --rebase, etc) pays big dividends that your team will appreciate more as the years go by. For git beginners maybe you start without rebasing, then learn the ins and outs of rebasing with local branches only before pushing, before finally going the whole hog and rebasing topic branches with force push before merging.
One last idea I like is Zach Holman's recommendation of deploying topic branches directly and then merging if there are no issues (https://zachholman.com/posts/deploying-software) in order to have easier rollbacks. Then you have 100% guarantee master is always stable.
The main cherry I like to put on top is to always rebase before merging then merge with --no-ff (which is the default with GitHub PR merge button). This gives linear history for purposes of git bisect but preserves the topic branch structure so you don't have to read the tea leaves of the individual commits to piece together the overall development timeline. That one little piece goes a long way to addressing the concern that "rebasing destroys history" (which I don't agree with anyway, but that's the topic of another post).
This might not be worth it for certain types of contributors who are not programmers by trade, but for career programmers I believe mastering git and rebase in all its flavors (-i, --onto, pull --rebase, etc) pays big dividends that your team will appreciate more as the years go by. For git beginners maybe you start without rebasing, then learn the ins and outs of rebasing with local branches only before pushing, before finally going the whole hog and rebasing topic branches with force push before merging.
One last idea I like is Zach Holman's recommendation of deploying topic branches directly and then merging if there are no issues (https://zachholman.com/posts/deploying-software) in order to have easier rollbacks. Then you have 100% guarantee master is always stable.