Working on multiple independent git-flow feature branches

[David Bainbridge]

What is the procedure for working on multiple independent git-flow initiated features? Let's say I have started one feature but stop working on that feature. I now want to start work on a new feature based on the "develop" branch but does not use anything from the feature I already started. I also want to keep the other feature's code for committing later.

Edit: I see this is a duplicate of this question but I am not clear about the two options in the answer given. I am keeping my feature branches local. If I commit the changes to a local branch "feature A" then start a new git-flow local branch "feature B" will feature B contain the changes for feature A (both are branched from the "develop" branch). Or is the better option to "stash" changes for feature A and start the new feature B branch?

[stevestreeting · Accepted solution]

You can commit your WIP changes to the feature branch, then start another feature. Features always begin from the develop branch anyway, but you can checkout the develop branch explicitly first if that makes you feel more comfortable. All feature branches are independent, they will only share code if one of them was finished (therefore merged back into develop) before the other was started.

[stevestreeting]

It might be worth clarifying that it's fine and indeed very common to have multiple feature branches in progress at once. You can't, however, have more than one release or hotfix branch in progress at once. This makes sense because you really only want to use these while you're preparing the next release / hotfix, there's no reason to have many of them in parallel.

[David Bainbridge]

Thanks. That clarified it for me.

[Krishan Gopal]

Here question is how do you test multiple features?

Do you have featureA.example.com featureB.example.com like setup so that QA can test all features simultaniously?

[DazJCampbell]

"there's no reason to have many of them in parallel"

Maybe not many, but I think we have a pretty good reason for having several of them in parallel: we work towards several planned releases in parallel. More specifically, we test towards several releases in parallel: while one release is in user acceptance test, the next is in system test, etc. We don't want to accept any new features for a given release while we test (and certainly not for a future, perhaps unrelated release), so wouldn't it seem reasonable to branch off for each release before we start testing? That being the case, we will usually have several active at the same time. Maybe it depends on whether you're working on a self-contained software product or, as we are, on elements of a business system that includes people and processes.