How to handle merge conflicts using Agile branch workflow?

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?

1 answer

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



Suggest an answer

Log in or Join to answer
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

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&nbsp...

654 views 0 4
Read article

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot