Ok with your change to the GitFlow process in step 3 you'll have to be 
careful about doing that merge back to master in step 4, in fact I'd say 
just don't do it. The reason is that you'll be diverging mater from develop 
and it'll soon become difficult if not impossible to manage and I wouldn't 
be surprised if things go wrong quickly, I could be wrong though. I think 
you might also find picking key commits from the develop branch to merge 
into your release branch is easier to say than do and that's not a Git 
limitation it'll be hard in any VCS I can think of. It does depend on what 
your tracking and the nature of the changes, so if every commit works on a 
different file and one commit never depends on a previous commit you might 
not have a problem but typically that's not a very common scenario (IMO). 
The whole GitFlow process is about working on features independently but 
being able to stitch features together when bringing them back to product 
as a complete feature so the develop branch at any single point in time 
represents *the* completed feature set of the product and could be released.

  From what it sounds like you want to achieve I wonder whether it would 
work if you merged the feature branches into release branches. So rather 
than merge everything into develop and then try to pick key features and 
merge them across into a release you would merge the feature branches you 
want into the release branches that feature is meant to appear in. Quite 
what the process would be with regards with what to do after the release is 
done I'm not sure. By diverging the release branch from the develop branch 
you're effectively creating a fork (or be merging particular feature 
branches into the release branches). Those forks aren't really in a 
position for merging back into develop or master either. 

  If I'm honest it sounds like you might be better using a *Feature 
* mechanism in your software (if that's what you're tracking) and then just 
follow the vanilla GitFlow process for developing features. I realise 
Feature Toggles are often advertised as being an alternative to the Feature 
Branch model but I think they can be mutually beneficial rather than 
mutually exclusive but that's probably a discussion for somewhere else :)



On Tuesday, May 21, 2013 11:39:30 PM UTC+1, Tony Quilkey wrote:
> Hi,
> I am looking at formulating and then documenting our vcs workflow
> using Git at work. I have an idea of how I want things to work, but am
> a little hazy on some of the details.
> Our basic workflow will be based around:
> http://nvie.com/posts/a-successful-git-branching-model, with a few
> exceptions.
> We would like to create our release-* branches from the last release
> tag. From there, we would like the ability to cherry pick (or take the
> complete diff) commits from the develop branch.
> So, we are after is:
> 1) Create topic (feature) branches from develop, and merge back into
> develop when complete.
> 2) Once it is decided we are packaging a release, make a release-*
> branch from the previous release tag.
> 3) Cherry pick/merge/whatever any commits we want from develop into
> the new release-* until it is complete.
> 4) Merge the new release-* branch into master and tag it.
> Repeat as necessary.
> At the moment I am a little stuck on how exactly we can cherry pick
> stuff from develop into a release-* branch. I'm not even sure this
> approach is exactly what we should be doing, but we definitely need 
> the opportunity here to filter stuff going into production.
> Our main concern is that at this stage, there is no guarantee that all
> commits within develop can be pulled into a release.
> In regards to how we can achieve the above results any input would be
> much appreciated. Or if there are any other better options available,
> I'm all ears.
> Thanks,
> Tony Quilkey

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to