@catweasel this has not been forgotten and some documentation has alreade been added as stated here.
@tonfilm also went over good practices here.
To add to that I recently came across this way of doing things and I am enjoying it a lot. The branching model is well known in the software industry and there are tools which support it (Bitbucket supports it by default, so does Github and Git for Windows so if you have Git and Windows you can already use it).
I am starting to use on my own VL and work repos and things remain very clean and easy to make sense of. Also it automates all the branching, merging, deleting old branches and naming things properly which is great, less chance for human error.
I essense you have 2 main branches:
- main or master : for releases only
- develop: for internal dev, can be used for prerelease, should remain stable at all times
and then you have some other additional branch types:
- feature/XX: individual features dev. Should branch off develop and merge back to develop
- release/YY: individual release branch, prepping the code for a release. Branchess off develop, merges into main/master. Must be tagged with a version number
You can also use hotfix branches which I rarely use.
The strategy in general is documented nicely here: https://nvie.com/posts/a-successful-git-branching-model/ (as seen in my previous post)
This of course is a preference of mine and your project’s demands could find this is too much to bear with, or too little. There is just no golden way to do things right on git.