How to handle merge conflicts using Agile branch workflow?

[Andrew Trevers]

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?

[Rich Duncan]

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

-Rich