Gitflow and Accidently Merging other features

Question

We've recently started to introduce gitflow, following mainly some youtube videos and some online articles - along with the GUI functionality within SourceTree.

However we think we're doing something wrong as we're hitting situations which we were hoping to resolve.

developer 1 is working on feature 1, developer 2 is working on feature 2, the develop branch is for development and is staging, the master branch is live/production

developer 1

1. develop = master (in sync with master)
2. develop -> branch to feature-1
3. develop <- merged in feature-1

developer 2

1. develop != master (isnt in sync with master)
2. develop -> branch feature-2
3. develop <- merge feature-2

Now we come to the problem, if developer 2 wants to put feature 2 live by merging it into master - it will contain feature 1, meaning they'll both go live.

So we're clearly doing something wrong - and this is what we need clarification from, the only 2 ways I can see around this off the top of my head are

• You create the new features from master rather than develop
• You use "Cherry Pick" which only takes the actual changed files into master

---

The solution we want is for mixture of web development projects that do not have release cycles, they literally go live once the client has signed off the feature, so suggestions on how to achieve this would be much appreciated.

Thanks

Answer 1

Well, as per the gitflow documentation http://nvie.com/posts/a-successful-git-branching-model/ :

Finished features may be merged into the develop branch to definitely add them to the upcoming release

So dev 1 should not merge feature 1 into develop until it is 100% guaranteed in the next release. And if that is the case, then it's no problem for dev 2 to branch off of that, including feature 1. When feature 1 is in develop, then it should be considered "done" except for bugfixes, it cannot easily be removed from develop.

That said, I find gitflow cumbersome and prefer http://dymitruk.com/blog/2012/02/05/branch-per-feature/ myself. Besides being structurally much cleaner, it has the huge benefit that it is trivially easy to back out features from the "next release" at any point, and that the "problem" you are facing (one feature implicitely bringing along another one) cannot occur.

Answer 2

When developer 1 merged feature 1 back onto develop, it should have been production ready.

Therefore there shouldn't be a problem realeasing feature 2 and feature 1 together.

But you have a few options here.

1. Don't finish feature 1 just yet (if it's not production ready, don't merge it back onto develop).
2. Release more often (release feature 1 first, as soon as it is finished).
3. Use feature toggling (have a property feature1.enabled=false) and release feature 1 along with feature 2, although the functionality is disabled.

Remember that under git flow, releases are always made from develop branch, so you should ideally be able to do a release from develop with production ready code pretty much whenever you want.