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.
