This is a Gitflow process question. In all the documentation (and diagrams) I've read about Gitflow, they always indicate that once a feature is completed it is merged back into the develop branch.

But the one thing that I never find defined anywhere is what the definition of "a finished feature"? Is testing (Quality Assurance, User-Acceptance-Testing, etc) supposed to happen in the feature branch itself, or is a developer supposed to merge their changes back into the develop branch as soon as they determine their implementation is complete (but prior to QA/UAT acceptance)?

Logically, I would expect QA/UAT to occur in the feature branch itself for the simple reason that otherwise poor quality code could find its way into the develop branch and contaminate other development branches.

However, if that is the case, does that mean that each new feature is tested independently of other features, and only once everything is merged into develop that a full regression test occurs across multiple features? Should full regression tests then only occur once a release branch is created?

  • 3
    A "finished feature" is whatever your development team says it is. Commented Oct 5, 2016 at 21:27

4 Answers 4


The feature should be tested on its own before it is finished and merged back in to the develop branch. However, I think its up to each team using gitflow to define what finished means. Each team should determine how much testing should be done in the feature branch vs. how much testing must be done after it is merged back into the develop branch.

There must be testing done on both the feature branch and the develop branch. It is reasonable to assume that the develop branch is in a different state than when you created your feature branch. That means that you will need a new round of testing for the develop branch after you finish the feature.

If you test your feature in isolation from any changes made to the develop branch, then if there is a bug after you finish the feature, you can use these test results to help focus where you are debugging your code.

It is really up to you and your team how much testing is done in the feature branch. But you should do a full testing on the develop branch after your feature gets merged into the develop branch. That may lead you and your team to do less testing, such as not doing a full UAT and only relying on Unit Tests for the feature branch, or it could mean some other amount of testing.


Teams have varying standards for considering features "done," but this part is generally considered to be when the developer is done. That doesn't mean you slack on the quality however. On my team that means it has passed a code review, has 100% unit test coverage, has automated integration tests, and those tests are all passing.

The reason is that there is a cost to isolating a branch for too long. The longer you go before merging back into develop, the worse the risk of serious conflicts when you do. Also, you have bigger pull requests that are more difficult to review thoroughly. The ideal lifetime of a feature branch is no more than a few days.

With several teams working at that rate, that cycle time is plain too fast for QA to handle, unless you have an abnormally large QA organization. You need to give them builds from a branch that aggregates features as a matter of pragmatism. In the gitflow model, I believe that's usually the release branches.


It's when you stop working on it. You are going to have to come up with your own criteria. Hopefully, your decision to stop is either you met the requirements or you've stopped trying. You'll also have to decide how to use the system if there are additional requirements or they've changed.

I don't know enough about Gitflow to determine if they just offer a tool or if they intend a specific methodology on managing software development. Most hammers don't tell you what nails to hit, how hard or how deep.


This definition is, as I remember it, from Jessica Kerr, not git flow, but a finished feature is one for which the code has been permanently removed from the production environment. As Kerr says, once it's stopped being useful and been deleted, "no-one will ever call you and ask you about it again".

  • Okay, let's not merge feature branches, until we remove implemented features from them.
    – Basilevs
    Commented Jul 15, 2018 at 19:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.