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?
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:
Hope this helps
As a project manager, I have discovered that different developers want to bring their previous branching method with them when they join the team. Some developers are used to performing individual wo...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs