Search code examples
gitagilebranching-and-mergingbranching-strategy

Git merge strategy for Agile Branching workflow

We're adopting a new branching policy to work with Agile and to enable us to release on a feature by feature basis, whereby we have a master branch and a QA branch as perpetual branches. Nightly builds will be based on QA 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 QA 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 QA (but not yet master)
  • Developer B ("Jane") has created feature/JanesFeature, carried out some work and is now attempting to merge into QA
  • Merge conflicts are now occurring for Jane, caused by changes introduced to QA 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 QA for obvious reasons. 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 QA 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 QA locally and pushed to remote without any pull request or peer review.

What would be considered 'best practice' in this situation?

Solution

  • Check out Git Flow. It comes closest to what you're trying to accomplish.

    Developers would branch their feature branch off the qa branch (called develop in Git Flow). complete their feature (regularly picking up the latest state of QA) and merge back to develop whenever possible (a feature is complete or it is in a stable state or it is turned off).

    What you run as a qa branch would likely be the release branch in Gitflow.

    Any change to master is immediately merged back to develop.

    See also: