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:
- Developer A ("Rod") has created
feature/RodsFeature, carried out some work and merged into Integration (but not yet master) - Developer B ("Jane") has created
feature/JanesFeature, carried out some work and is now attempting to merge into Integration - Merge conflicts are now occurring for Jane, caused by changes introduced to
Integration by Rod's merge of feature/RodsFeature
If Jane were to bypass QA and merge feature/JanesFeature into 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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.