restriction of Gitflow release branch in team

Question

I am excited to find an comprehansive answer about my quastion. Here is it:

In my team we are using gitflow as a workflow to develop and release our projects. Now we are having a conceptial problem with gitflow.

When we decide to release, we push our work to release branch, where the QA and the customer test the code and response with a set of bugs or change requests of the current feature (No new feature as gitflow suggest).

The problem is when we want to fix bugs, as we need to work as team, many people should work on the same release branch. Therefore, either we are facing conflict problem through working togather or we have to work consequential which is not efficient to do the job.

We had the idea of creating new branches from release and working parallel on these branches, but we still feel that this is not the best way to do that.

What is the best way to let a team work parallel on a release branch to fix bugs?

Answer 1

There's obviously no right or wrong here, but I suggest that you let QA & customer test feature branches independently. That way the scope of each testing session will be much smaller and easier to handle, and you can fix any problems without conflicting with other branches. Once your branch has been tested and fixed, you can move it to the release branch.

Answer 2

This may not be the answer you're looking for, but for me an important part of the git flow methodology is that everything is branched and merged (via some sort of review process/pull request).

For this reason, I'd definitely recommend that you branch off your release branch and merge back into it. One obvious con from not branching is that you don't have a step to implement a review (like a pull request) without someone doing a fetch and check, at which point the commit is already in your release branch (bad!). Also, you could have two people commit and push at once, etc etc.

Having said that I know that this may not fit completely with the git flow process in that features and bugfixes are branched from develop , releases from develop and hotfixes from master , but you should also keep in mind that git flow is really just a concept, a guide and a mindset to adapt. The command line tools for it are just to help you out.

For example, at my current job we started trying to use git flow in its purity (and we have a similar sounding scenario to you) and found we ended up using the concepts but managing the branching ourselves and the merging in GitHub pull requests rather than your standard git flow feature finish type scenario. The main reason we did this is to avoid multiple developers finishing and pushing a feature at the same time .

I hope this helps you.