We are a small software team with 6 members. We are working on different software projects in our company. Before I joined the team no version control system was used. It was/is my task to reorganize the team and daily work to use vcs (git with own Gitea server).

I'm now on that point where I have to find a appropriate branch strategy. I studied things like git flow, GitHub flow etc. But none of them seem to fit my needs (or I don't understand them correctly).

So here is what I have in mind and are currently using:

First we have our master branch. Pushing is restricted. Changes are only allowed via pull requests. New features are implemented on branches named like feature/new-function.

I want to define milestones like Release 1.3 with a bunch of issues/feature request which should be completed to reach the milestone.

All these new features, fixes etc. are getting merged into the master branch. When milestone is reached, a new branch from master is created named release/v1.3. After the branch is created a release/tag v1.3.0 is created. (Gitea actions workflow creates docker image and pushes them to a registry). Now we can define a new milestone for example release 1.4. New features get developed and merged into master if they are ready. When milestone is reached, we can create new release branch and release tag.

So far, so good. But know bug fixing/Hot fixing: Imagine we are working on Release 1.5. Meanwhile a bug in version 1.3.0 and/or 1.4.0 is reported. How to deal with it? My suggestion would be to create a new branch bugfix/dumb-error from oldest release branch to be supported (i. e. release/v1.3), fix the bug, push and then merge this branch into all release branches which are same or newer than oldest supported version (release/v1.3, release/1.4) and of course into master, where currently work for release 1.5 is happening. After that, we can create new release tags v1.3.1 and v1.4.1 which now include the Bugfix. Release 1.5 will contain fix from first release tag on.

Is this a strategy considered correct/ best practice or are there any bug drawbacks I don't see now?

Are there improvements I can make or is my strategy complete nonsense and will give me a lot of headaches in future? What are the alternatives?

Any suggestions/comments are welcome! Thank you!

We are a small software team with 6 members. We are working on different software projects in our company. Before I joined the team no version control system was used. It was/is my task to reorganize the team and daily work to use a vcs (git with own Gitea server).

I'm now at that point where I have to find an appropriate branch strategy. I studied git flow, GitHub flow, etc. But none of them seem to fit my needs (or I don't understand them correctly).

So here is what I have in mind and this is what we are currently doing:

First, we have our master branch. Pushing is restricted. Changes are only allowed via pull requests. New features are implemented on branches named like feature/new-function.

I want to define milestones like Release 1.3 with a bunch of issues/feature requests which should be completed to reach the milestone.

All these new features, fixes, etc. are merged into the master branch. When the milestone is reached, a new branch from master is created named release/v1.3. After the branch is created, a release/tag v1.3.0 is created. (Gitea actions workflow creates docker images and pushes them to a registry). Now we can define a new milestone, for example release 1.4. New features are developed and merged into master when they are ready. When a milestone is reached, we can create a new release branch and release tag.

So far, so good. But now bug fixing/hot fixing: Imagine we are working on Release 1.5. Meanwhile, a bug in version 1.3.0 and/or 1.4.0 is reported. How to deal with it? My suggestion would be to create a new branch bugfix/dumb-error from the oldest release branch to be supported (i.e. release/v1.3), fix the bug, push and then merge this branch into all release branches which are the same or newer than the oldest supported version (release/v1.3, release/1.4) and of course into master, where currently work for release 1.5 is happening. After that, we can create new release tags v1.3.1 and v1.4.1 which now include the Bugfix. Release 1.5 will contain the fix from the first release tag onwards.

Is this a strategy considered correct/best practice or are there any big drawbacks I don't see now?

Are there improvements I can make, or is my strategy complete nonsense and will give me a lot of headaches in the future? What are the alternatives?

Any suggestions/comments are welcome!