Best practices for gitflow in an open source project

Jonathhan Goor 0
Viewed 26

I'm starting to work on an open source project at work and we're trying to establish a healthy gitflow branching strategy.

Currently, the best option I've found is the "GitLab workflow with release branches". Git Flow Image

It seems ok but there are a few questions that come up with this method:

  1. What happens when I fix a bug in an older version, let's say: v1.2.0 -> v1.2.1. Do I need to cherry-pick the commit to all the newer versions?
  2. How to deal with release candidates? Do I branch from the release branch: v1.2rc_1 or are there better practices for that?

Thanks!

open-source gitlab git github
1 Answers
  1. Does it really makes sense to fix bugs for older version? In most cases - especially for open source projects - bug fixes are introduced into the newest commits. It makes sense to fix bugs for particular versions if you had some breaking changes, and users can't simply upgrade to the latest software. So it also depends on how your software is distributed and used.
  2. Release branch is release candidate itself already. That is the code, which you are going to release. And after that, released code will be merged to master at the end. So no additional branches from release branch are needed in git flow model.
kosist0
Related