This question already has an answer here:
Currently we use a branch "stable" from which our CI takes (by default) the last commit when building a new release.
However I also keep seeing people suggest using tags for this, and just use "master" branch instead. - Currently "master" is used for nightly builds and other in house use.
The advantage of using branches is that (to me) it was easy to split stable and nightly: every once in a while master is merged into the stable branch.
However someone else rightly stated that using tags allows for better control, and easier to go "back" to an always working version. While keeping the git repository in a clear linear state.
So now I'm wondering: should we just use a single "master" for releases, and just use tags (with special names) to denote "stable"? Or use branches? - Or even both?
To clarify: we would use "branches" for each of the release routes: "nightly", "long term stable", "current", "maintenance mode only", "deprecated". This would still allow development to continue on said branches, while not creating many branches in the git repository.
So I'm wondering how would this system compare (in long term) to the proposed systems in the linked question.