Ability to select feature branches to merge into master

[Greg Froese]

Short story:
I would like the ability to choose which feature branches get merged into a release branch.

Full story:
I don't always have the luxury to control what is getting merged into my develop branch, and therefore when preparing a release, I may need to exclude some features from the release that are not yet complete.

When running "git flow feature finish <branchname>" it gets merged into my develop branch, but it also deletes the feature branch.
Would it make sense to keep the feature branch around (optionally) and merge it into a release branch after it has been tested and approved?
This would allow all sorts of half-finished or untested features to be merged into the develop branch without affecting the deployability of the release branch.

I'm surprised everybody isn't running into this same issue.
Am I overcomplicating things or does this make sense?
gf

[justin]

On Thu, Aug 19, 2010 at 11:12 PM, Greg Froese <greg....@gmail.com> wrote:
> Short story:
> I would like the ability to choose which feature branches get merged into a
> release branch.
>
> Full story:
> I don't always have the luxury to control what is getting merged into my
> develop branch, and therefore when preparing a release, I may need to
> exclude some features from the release that are not yet complete.

It sounds like your feature branches are being finished before the
features are actually finished. We had a similar problem on my dev
team, and we instituted a very strict approval process before
'finishing' feature branches. No feature branches are finished unless
that particular feature is actually complete, *and* it is slated to be
in the next release. So now we have a lot of feature branches hanging
around in our central repo, but our dev branch is always deployable.

> This would allow all sorts of half-finished or untested features to be merged
> into the develop branch without affecting the deployability of the release branch.

Yup, that's your real problem right there... Develop branch can be
merged into half-finished and untested feature branches, but not the
other way around. Feature branches aren't "finished" until they're
actually ready to deploy.

For testing, UAT, etc. we regularly deploy incomplete feature branches
to our dev or staging servers (via a normal `git checkout
feature/foo`), but the `develop` branch is expected to be releasable
at any given time.

In fact, our continuous integration server runs our test suite any
time there's a commit to the develop branch. If something breaks or
there's a regression in that branch, the developer who finished the
incomplete feature is responsible.

--
justin
http://justinhileman.com

[Mark Derricutt]

This sounds like my idea of an "integration" branch I floated awhile back.  Basically the idea would be:

$ git flow integration start xxx

-> git checks out develop

-> create branch integration/xxx

-> merge all feature/branches ( maybe cherry pick features? ) into integration/xxx 

You'd not want to release from here tho.

--
Pull me down under...

[Greg Froese]

I think this could be solved a few ways:

1. git flow feature finish <name> does NOT delete the branch, but merges it into develop and leaves the branch hanging around.  Of course this can be done with git merge feature/<name> but it doesn't give you any indication of the state of a feature branch.
2. git flow feature test <name> would do the same thing that feature finish does now, except would not delete the branch.  When testing has been completed on the develop branch, then you could run git flow feature finish <name> that merges the branch into either an integration branch or a release branch (I have very little experience using the release branches so I'm not sure which is the better option here).  Running a suite of integration tests on that branch as part of a hook and you've got a fully deployable branch at all times that does NOT include all actively developed feature branches.

At first glance, I think option 2 is pretty close to my ideal solution.

gf

[Vincent Driessen]

Hi Greg,

On Aug 20, 5:12 am, Greg Froese <greg.fro...@gmail.com> wrote:
> Would it make sense to keep the feature branch around (optionally)

This would be a good candidate for a flag in the finish command, for
example:

git flow finish --keep foo

However, the original intent of the develop branch is that it is the
branch used to pick the features for the next release.

If you feel the desire to make sure whether changes in a certain
feature branch don't conflict with changes made on the develop branch
in the mean time, a better solution might be to use either a manual
merge of the develop branch into the feature branch (nothing wrong
with that), or rebase your feature branch to the latest develop head.
That's as simple as:

git flow feature rebase foo

Problems occur only when you want to make sure two *feature branches*
have conflicting changes. You could indeed introduce the concept of a
separate integration branch and merging in both features, like this:

git checkout -b integration develop
git merge feature/foo feature/bar

Then, you'd need to fix conflicts and patch anything to make it work.
If done, you want to checkout develop and merge the integration work
into it. Of course, thinking about it this way immediately leads to
the thought of needing yet another git-flow subcommand (as proposed by
Mark elsewhere in this thread). However, I think git-flow is at the
limit of the required complexity with four different subcommands
already. I feel strongly about _removing_ more subcommands than
_adding_ them.

But hang in there—not all it lost yet!

I thought about how we deal with these situations here internally, and
quite frankly I realised that we use the develop branch for
integration work. Let me explain.

The beauty about Git is that everything is local. So why not finish
those features into the develop branch. Since the develop branch is
locally available to you (the integrator) alone, this won't affect
anybody and you have the room to test and patch the sources. Once you
are satisfied with the result and your develop branch is stable again,
you simply push out the changes to origin. It's really simple, solves
your problem (I believe) and does not change anything to the original
article and the git-flow tool.

(Although I still think the --keep flag is a good extension, so you
are able to undo the finish, by undoing the merge commit. I've files a
ticket for this one at http://github.com/nvie/gitflow/issues/issue/43)

Hope this helps you.

Cheers,
Vincent

[Greg Froese]

Thanks for your reply Vincent.
The trouble in my situation with merging to develop locally first and testing there is that is only one phase of the testing process.
After the developer completes his initial tests, the develop branch (with the feature merged) is pushed to origin and tested again by business analysts.  This often results in a back and forth bug fixing on each feature between the business analysts and the developers, and with the current git flow setup, forces the developer to create a new feature branch to fix bugs in the existing feature that is now incomplete because of failed tests.

Discussing this with one of my developers today, one workaround would be to push the feature branches to origin _before_ finishing the feature.  As soon as the feature is verified by the business analysts, the feature branch could be merged into the integration branch.
The issue I see with this is human error and laziness.  If an incomplete feature branch gets merged into the integration branch because the developer forgot to push a set of fixes to the feature branch into origin during the testing cycle, you would have incomplete code accidentally merged into the integration branch.

What do you think of making the following 2 items optional when finishing a branch (preferably in the config file so command line switches are not necessary each time)?

1. push the feature branch to origin prior to deleting it or merging it into the local develop branch
2. merge the feature branch as usual into develop, but don't delete it

It seems logical if you have the local feature branch available even after finishing a feature, you could create a new command for git flow feature that merges that feature into the integration branch on origin.
git flow feature integrate <featurename>

This step could perform the merge and then delete the feature branch.
As it becomes clearer as I type this, I think this would be my preferred method.  It would keep the origin cleaner by not having a bunch of feature branches on it, and also clean up a feature branch locally when you have it in a verified state.

Looking forward to your thoughts.
gf

[Vincent Driessen]

Hi Greg,

On Aug 24, 7:57 am, Greg Froese <greg.fro...@gmail.com> wrote:
> What do you think of making the following 2 items optional when finishing a
> branch (preferably in the config file so command line switches are not
> necessary each time)?
>

>    1. push the feature branch to origin prior to deleting it or merging it

>    into the local develop branch

Have you already tried the following command:

git flow feature publish foo

(Which would push out feature branch "feature/foo" to origin. Note
that this currently only works for remotes called "origin". This is
something git-flow could improve on.)

> 2. merge the feature branch as usual into develop, but don't delete it

I feel for this extension, and I've filed it under this issue:
http://github.com/nvie/gitflow/issues/#issue/43

> It seems logical if you have the local feature branch available even after
> finishing a feature, you could create a new command for git flow feature
> that merges that feature into the integration branch on origin.
> git flow feature integrate <featurename>

I really believe that this is the beginning of feature creep, which I
would like to avoid as long as possible. I don't know if you have
another alternative for working together on branches, but if you work
in a agile setting with the business analysts, you could consider
directly fetching local using the "git flow feature pull" command, for
which the currently available documentation is this commit message:
http://github.com/nvie/gitflow/commit/f68d405cc3a11e9df3671f567658a6ab6ed8e0a1

> As it becomes clearer as I type this, I think this would be my preferred
> method.  It would keep the origin cleaner by not having a bunch of feature
> branches on it, and also clean up a feature branch locally when you have it
> in a verified state.

I can understand your needs and wishes, but I think the model would
become increasingly more complex (and it is already too complex, if
you ask me). So I'm not a big fan of adding the integration branch
right now. Let me know if the alternatives I've mentioned in this
reply work out for you.

Cheers,
Vincent

[justin]

On Wed, Aug 25, 2010 at 4:03 AM, Vincent Driessen <nvi...@gmail.com> wrote:
> Hi Greg,
>
> On Aug 24, 7:57 am, Greg Froese <greg.fro...@gmail.com> wrote:
>> It seems logical if you have the local feature branch available even after
>> finishing a feature, you could create a new command for git flow feature
>> that merges that feature into the integration branch on origin.
>> git flow feature integrate <featurename>
>
> I really believe that this is the beginning of feature creep, which I
> would like to avoid as long as possible. I don't know if you have
> another alternative for working together on branches, but if you work
> in a agile setting with the business analysts, you could consider
> directly fetching local using the "git flow feature pull" command, for
> which the currently available documentation is this commit message:
> http://github.com/nvie/gitflow/commit/f68d405cc3a11e9df3671f567658a6ab6ed8e0a1
>

Greg,

git is built to do things like integration branches. I build (and
discard) them all the time... Right now git-flow is an abstraction
around common git workflows that take too many steps. In this case,
the vanilla git way is pretty straightforward, and would take the same
amount of typing as a git-flow canonicalized implementation:

git checkout develop
git checkout -b integration/foo-bar
git merge feature/foo
git merge feature/bar
git push origin integration/foo-bar

--
justin
http://justinhileman.com

[Greg Froese]

Disclaimer: I may be going off the deep end here, but I really want to leverage git and git flow to allow me to release all completed features at _any_ time, so bear with me.

Justin,
I agree, this integration piece can all definitely be handled with the vanilla git commands.

The benefit of having the integration piece built into git flow would be found in consistent processes for your development workflow.
Using git flow for something and vanilla git for others is not the end of the world, it just requires strict adherence by the developer.

Here is a description of what I want my workflow to be able to do:

My main goal is to have a branch that is always deployable despite having some incomplete features being developed and/or tested.  I don't always have the luxury of being able to set my release points and deciding ahead of time what is and what is not included in a release.

The git flow workflow as described by Vincent works well for this when all testing is done locally by the developer, but it does not address the situation where a separate team of people are testing the features in a Quality Assurance (QA) environment.

Basically the following situation happens all the time in my team of 3 developers and 2 Business Analysts:

• feature A has been started and is still local on the developers repo
• feature B is finished, merged into develop, and tested and ready to release
• feature C has been started, was "finished" by merging it into develop for testing in the QA environment.  Testing has not yet occurred
  
• feature D has been started, was "finished" by merging it into develop for testing in the QA environment.  Testing has failed and the feature is going back to the developer
• feature E is finished, merged into develop, and tested and ready to release

Along comes the marketing emergency that requires we release features B and E immediately.  Using the basic git flow workflow I cannot do this because features C and D are in the develop branch already but not in a ready to release state.
Enter the integration branch.  Features B and E get merged into the integration branch, unit tests are run, and I can now release features B and E by using the integration branch despite the fact that features A, C, and D are incomplete, especially the more problematic features C and D that have already been merged into develop.

So now I believe my workflow looks like this:

1. git flow feature start foo
2. <work by developer>
3. git commit
4. git push origin feature/foo
5. git flow feature finish foo
6. git push origin develop
7. business analysts test
1. if feature is broken or fails tests then developer must go back to step 1 which is redundant because the feature should never have been finished until it was actually finished and verified by testing team.  This is why I really would like to see the option to keep the branch so you're not restarting the same branch over and over, but rather continuing it to maintain some sanity in the commit logs and actually merging the entire feature as one commit into the integration branch
2. if feature passes testing, continue
   
8. git checkout --track -b feature/foo origin/feature/foo
1. This is where I need my feature branch to still be available locally, but this will do for now to prove the workflow
9. git checkout integration
10. git merge feature/foo
11. git push origin integration

This workflow is definitely a bit more overhead, however, giving me the flexibility to release all completed features at _any_ time without consideration for the items that are in progress either in development or testing is well worth the effort, and to meet the business needs of my users, critical to success.

Any suggestions to simplify this are very welcome.

I should also note I tried git flow feature publish but it does not allow me to add in more changes to the branch on origin.  If the branch is not on origin, it works, but as the development and testing is an iterative process, git push is what I need to update the branch on origin.
gf