We're implementing the "Git branching for Agile teams" workflow as suggested in this video whereby we have a
master branch and an
Integration branch as perpetual branches. Nightly builds will be based on
Integration and releases will come from
master. Developers will create a feature branch for each story. All feature branches are to be branched off
master, and then merged into
Integration for testing, followed by a merge of the feature branch into
master for subsequent release. This is fine, until the following scenario:
feature/RodsFeature, carried out some work and merged into Integration (but not yet
feature/JanesFeature, carried out some work and is now attempting to merge into
Integrationby Rod's merge of
If Jane were to bypass QA and merge
master, there'd be no conflicts as
feature/RodsFeature is not yet in
master. However, Jane must merge into
Integration for QA purposes. In order to resolve the conflict, she could pull and integrate Rod's changes into her feature branch, resolve the conflicts and then carry out the merge - with the undesirable consequence that once she merges her feature branch into
master it'll also introduce Rod's changes which are still pending QA testing.
So - a workaround would be to resolve conflicts directly on the
Integration branch, leaving Jane's feature branch intact for later merging into
master. However, this breaks code review policies, as merges should be approved by a peer - by doing this, she has merged into
Integration locally and pushed to remote without any pull request or peer review.
What would be considered 'best practice' in this situation?
I quick look into this indicates that the integration branch is only intended to determine integration issues between feature branches by attempting to integrate them and run a build which presumably determines that the code compiles and that tests pass. Commits on this branch don't 'go' anywhere - the branch is never merged down to master or back into feature branches. It is not a good idea for QA testing since the code there has not been delivered (features have not been pull-request/merged into master).
Once Jane is away of the conflict with Rod's work, she and Rod and determine the best course of action - make corresponding changes and re-merge their features with the integration branch to get a good build. Then they're more likely to deliver their respective features to master with out issue. Master or a release branch would be a better choice for creating release candidate builds that goto QA ... Production
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot