0

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!

7
  • 2
    For a small software shop, the approach that you describe sounds ideal. The only critique I would offer is that feature branch names ought to include a ticket number, so you can tell what modifications are in scope for that feature branch, and so you can tell when the feature is done, that is, when the ticket has been closed out. Otherwise there is a tendency for feature scope to creep, so a feature branch will last for a little more calendar time than was originally envisioned for it.
    – J_H
    Jan 17 at 21:10
  • @J_H The OP doesn’t mention using a “ticket system” so I don’t see how ticket numbers are relevant to the scope of this question. Jan 17 at 22:36
  • 1
    @Guildenstern yes. Didn't mentioned it in first place. But I want to work with milestones and issues.
    – Jakob
    Jan 17 at 22:41
  • 1
    @Guildenstern, yes OP mentioned "Gitea server", which offers issue tracking.
    – J_H
    Jan 17 at 23:05
  • 2
    @amon I think nvie gitflow (nvie.com/posts/a-successful-git-branching-model) seems way more complicated than what I described. Ye, I thought about having only one version to support. But in our company features are often getting deployed very early to customer machines. Meanwhile other customers stay on an older release an should also get Bugfixes, while newer version is "tested" in production on customer machine.
    – Jakob
    Jan 18 at 6:27

3 Answers 3

3

If you make sure that the master branch can be released at any time, so that the following conversation can happen:

CEO: Is New feature X already done?
You: Yes, it has been tested and merged.
CEO: Good. I have a customer who needs that feature ASAP. Forget about what else we had planned for the next release, I need a new release tomorrow morning.
You: No problem. We will start making the release now and then it will be done in Y hours.

If you can support that, then you are effectively doing Github-flow with an adaptation for providing bugfixes on older releases.

Note that there is a difference between being able to deploy multiple times a day and actually doing so. While GitHub-flow officially states that you should deploy as soon as something is merged to master, there can be very legitimate business and logistical reasons to deploy new versions with a lower frequency, even down to once every few months.

1
  • Great. Especially the assumed conversation. I expect to have conversions like this from time to time. So I thought about this. I guess with my approach I am able to create Pre-Releases like 1.5-beta from master branch, where all (tested) features which are completed up on this point are included. Thank you for your thoughts on my strategy!
    – Jakob
    Jan 18 at 12:41
4

This exact workflow I've successfully implemented for my projects.

There is a minor complication though: we use Maven and it implies that for each patch/bugfix a version defined in pom.xml file is updated. This complicates the merge of changes from older to newer releases - we have to "skip" version bump commits by using git merge -s ours command. Otherwise, it works perfectly well and achieves seamless propagation of bugfixes.

2

I actually had same question some time ago here: https://stackoverflow.com/questions/73109008/release-branch-process-how-to-merge-release-branches

The answer I got and accepted seems similar to your way how to do it:

See also Raymond Chen's series of blog posts describing this same idea. Note that this general plan, "go back in time and fix the bug and then merge the fix forward in time", works for all the bug cases, and doing the "cherry-pick back in time so that we can merge forward" technique works in all the bug cases. The fix need only be merged in any commit that is a descendant of the bug, and does need to be merged in every release that is a descendant of the bug, and the fact that it is or is not merged tells you whether the bug is or is not fixed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.