Different models for source control have many camps. I would rather have my software teams focus on principles of usage before worrying about the specifics or the ‘right way’ to do something. The principles I suggest below should be easy to follow, and share with new team members.
1. Prefer distributed to centralized source control.
Git is so ubiquitous now, that this is nearly a non-issue, but if your team is still using a centralized repository (SVN, or TFS), you should SERIOUSLY consider resetting that model, if for no other reason because it will become impossible to find modern developers with experience in the centralized model.
2. The main branch represents the latest version in ‘production’ at all times.
Invariably, a product will have features in flight when something immediate (a bug, a feature request, a security update) takes over priority. Maintaining a ‘hotfixable’ version of production code at all times is crucial element of product ownership. Teams should updating the main branch with the updated code immediately after a release to production.
3. Work must be visible from a distance.
Developers not embedded on the product team should be able to look at a source repository, and quickly assess what work is being done, by whom, and according to what priority. This is typically done through consistent branch naming. Consistent branch naming makes it easy for team members to quickly onboard, and for larger CI / CD processes to be built off of those processes.
4. Leave nothing behind.
Keeping a tidy repository will avoid confusion, and ensure that only what is current and open is worked on. Branches left open can be committed and pushed to accidentally, leading to work missed, and potential breaks in CI and CD processes.
Christopher Brown's - Blog 