Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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?

like image 816
Andrew Trevers Avatar asked Aug 25 '16 14:08

Andrew Trevers


Video Answer


2 Answers

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:

  • https://www.atlassian.com/git/tutorials/comparing-workflows/
like image 87
jessehouwing Avatar answered Oct 20 '22 00:10

jessehouwing


tl;dr: add a dev branch to do pull requests of specific 'task' branches with the changes for code reviews.

On some team projects I've been on there was also a dev branch to do "pull requests" on Github or some repository manager where a senior dev looks over what has changed and sees if that specific change is well-written etc.

In online repo host environments like Github, they have explicit ui showcasing the changes back to back with the original branch etc. After looking over a branch, the senior dev then moves it into the Dev branch to ultimately be hosted in a qa environment to be looked over by the end of the sprint.

like image 31
alr Avatar answered Oct 20 '22 00:10

alr