Support for 'feature' or 'fix' branches off release branch

[Jon Palmer]

I'm evaluating git-flow and trying to understand if it supports some
of the common workflow we'd like to use. One particular area I can't
figure out is support for 'fix' branches off a release branch.

The flow would look something like this:

1. dev work for release 5
2. hit feature complete -> git flow release start 5
3. bug fixing
4. close release -> git flow release finish 5


However in step 3 we are likely fixing many bugs. Ideally each bug
would get fixed in its own branch based off release/5. That allows us
to keep the release branch clean, conduct code review on the bug fix
before merging to the release branch etc. etc. (much like a feature
branch off develop). What I'm really looking for is a git flow
commands like

git flow fix start bug123 release/5
git flow fix finish bug123 release/5

which would create and close a branch called something like: release/5/
bug123

Does the current version of git-flow support that workflow?

Thanks
Jon

[Vincent Driessen]

Hi Jon,

The workflow that you describe here is indeed quite common. Currently however, git-flow does not provide any commands to assist you with this. Mostly, to keep things simple. Providing extra commands for this would increase the complexity of the tool's logic, which isn't a problem on itself, but git-flow is currently only a collection of shell scripts. And shell scripts aren't the perfect base language for extension and growing of tools.

I might include a feature like this in the Python version of git-flow that I'm currently cooking up slowly. Until then, please keep on using this workflow manually. You can simply use the plain old Git commands:

git checkout -b bug123 release/5
(fixes here)
git checkout release/5
git merge bug123

Cheers,
Vincent

[Jon Palmer]

That makes sense. Can we contribute to the Python version? Are there
particular areas that could benefit from some more cycles?

[Jon Palmer]

Another thought I had that might be a workable solution would be to
expose some of the common logic into some utility methods. Presumable
the finish commands on hotfix and release share common code. Maybe
they can be exposed by a new util command so you could do this:

git flow util finish release/5/bug123 release/5

which would merge the bug123 branch into release/5, using the same -
noff options etc. and close the bug123 branch.

If you pick a reasonable branch naming convention you could make the
last argument optional so it would just be:

git flow util finish release/5/bug123

with the convention that branches get merged into their parent branch
by default.

Thoughts?
Jon

On Nov 18, 2:30 am, Vincent Driessen <vinc...@datafox.nl> wrote:

[Marijn Huizendveld]

In my opinion it is important to be explicit rather than short. You wouldn't want people to mess up because they don't realize what merge they are performing.

Just my 2c. 

Kindest regards,

Marijn

[Jon Palmer]

Maybe but simple conventions are powerful, indeed the entire premise of git flow is use convention to keep the commands short. Compared to the actions that 'git flow hotfix finish' does by convention (merge to release, merge to dev, merge to master, close the hotfix) I'm not sure why one merge into its originating branch would scare you.

Jon

[Marijn Huizendveld]

My reasoning was that in most of the documentation and blog posts about git flow there is no mentioning of having topic (read: bugfix) branches for your release branch. Hence people might not realize this requires some naming scheme. 

But in hindsight, I guess you're right :-)

[Marie Agen]

but I see but I don't understand it well