In gitflow if we have a release branch open for one week can we still merge feature branches into develop

Question

In gitflow if we have a release branch open for one week can we still merge feature branches into develop.

We have a release branch open for a while because we do the cut off from develop and we keep the release branch open for one week. But at the same time we need to merge things back to develop. Is that correct? or we should do it in another branch temporally or release branch should not be open for so long? any thoughts?

Answer 1

Once you create a release branch from develop, everything that gets committed or merged to develop is basically for the next release.

Imagine your current release is 1.0 (so master is on 1.0 ) and you have finished implementing features for 1.1 in develop . You then branch release off of develop an increase the version number there to 1.1 . From this time on all changes that go to develop are for version 1.2 . If you need to fix stuff for release 1.1 , do it on the release branch. However, it should be only small, polishing changes ideally. If you fear that these changes may interfere too much with the parallel development for 1.2 that simultaneously takes place on develop , you may also introduce these changes also in develop and any feature branch that is still being developed on. Depending on the changes you can do so by either merging release to develop or by cherry-pick ing individual commits. You may want to read how to merge a specific commit in Git and also the differences in Git Cherry-pick vs Merge Workflow .

Personally I don't see any problem with merging the version number change from release to develop before all work on release is finished. I would just make sure that my merge comment clearly tells that this is not the final merge but some intermediate one.

At the end one should keep in mind that git flow is only a measure to help developers organize their work. One should not make it a daily struggle to follow it strictly if in the end it does not fit the teams internal workflow.

Also see Vincent Driessen's blog post that introduced git flow and a (slightly opinionated) comparison of different branching models by Atlassian .