gitflow branching strategy with bitbucket

Question

I am trying to implement gitflow branching strategy and trying to understand how to resolve the problem I am facing. if you think there is a better branching strategy which could solve this issue please let me know.

how to handle parallel releases

let's consider two team are working on two releases. and each developer created feature branching from develop branch.
feature f_1 and f_2 are part of same release (release_f), however n_2 feature is part of different release (release_n) which team_2 is working on it.

develop
    --feature/f_1 (team_1/dev_1)
    --feature/f_2 (team_1/dev_2)
    --feature/n_1 (team_2/dev_1)
    

However, while merging into develop. this happened.

0.0.1------f_1-----n_1----f2--

Now how do I create two different releases such that, release_f contains f_1 and f_2 or exclude n_1 as release_n is not fully ready to be tested.

Answer 1

While gitflow is commonly used, many people are criticizing it. And for good reasons in my opinion. It is too complex and not adaptable.

So in your case the develop branch contains the common base that both releases are bases on. Your strategy will then be to create one branch release_f from develop where f_1 and f_2 are merged into and another branch release_n from develop where n_1 is merged into. That's the main core structure.

Then there are the details that only can be answered with specific knowledge of the product itself, e.g. should x_3 and y_5 be merged into release_f and/or release_n as well? Which of the features from the release branches should be merged into the develop branch as well? Should some of the features be possible to enable/disable compile-time with feature flags (e.g. #ifdef)? Etc.

So my recommendation is to look (briefly) at gitflow followed by looking into some of the other strategies, and then find what works for you. Start rather simple than complex, you can (and most likely should) always change later.

In my opinion the two key points in a sound branching strategy is the following:

• You have a branch which is tagged every single time a release is made¹.
• When you need to make updates/bugfixes to a release made earlier you create a maintenance branch from the corresponding release tag.

The rest is details.

---

¹ Notice "a branch", not "one branch". It can be different branch for different releases.