Question on Feature Branching workflow

Question

Consider the following scenario related to Feature Branching workflow:

Master Branch // Always contains tested, ready to release code*
Feature A // Branched off master to create feature A
Feature B // Branched off master to create feature B

Feature B is completed and a pull request is made so Quality Control can begin testing using the Feature B branch. It passes and Feature B is merged to the Master Branch. The Feature A branch is completed days later and a pull request is made.

Does Quality Control now begin testing on the Feature A branch without the already tested, approved, and released Feature B? What would be the best way to ensure both features are in his test build without breaking the rule of always having master consist of tested ready to release code?

My first instinct is to have a development / release candidate branch, but isn't that more consistent with the Git Flow workflow rather than the Feature Branching workflow?

* Am I wrong that Master should always contain tested, ready to release code? Should my Quality Control guy merge with Master, test, and possibly revert if it fails QC?

Rich Duncan · Accepted Answer

So if you get 4 experts in a room, you'll have 5 answers to this question...

In order for Feature B to be delivered (pull request + fixes + approval + merge), it must merge in the latest master that contains Feature A and whatever else was delivered to master after the feature branch was created. At that point Quality Control could:

* Build/test off of master and add bugs (in JIRA) to be scheduled to be fixed at a later time.  This would mean somewhat continuous and on-going QA.  Probably not what you want if you're doing manual QA testing since it involves too many testing cycles.  However if you do this, you have a much better idea of your quality status.  This is an ideal way to go if you have automated functional testing.
* Create a release candidate branch and test off of that.  Create bug-fix branches off of the release candidate branch to fix testing  bugs and merge them back into both the release candidate branch and the master branch.  Now you're into a git-flow derivative (as you said) and you're your testing is on the right side of the gantt chart when you want it as left as possible.
* Another approach I've seen is to use an Integration Branch which holds the completed Feature A, B, ... that need to be tested together.  Bugfixes branches are used to fix issues found in testing and are merged back to the Features (if they are still not delivered) and master if they are.  This lets you test completed things before releasing and even before the features are individually delivered at the cost of a more complex branching model.

Hope this helps

-Rich