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.

marked as duplicate by gnat, Robert Harvey Jun 14 at 14:38

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • @gnat while almost similar it doesn't handle the initial system we had anywhere in that post, so I find it difficult to compare. (Single branch per release type, long term stable, current, maintenance etc). – paul23 Jun 14 at 12:05