How to handle Git continuous integration merge conflicts

Question

We are in the process of outlining and preparing for a Git integration and we are implementing a similar design to the following link.

http://nvie.com/posts/a-successful-git-branching-model/

The issue we are running into is when you commit and push to the 'develop' branch or continuous integration branch, since we have multiple teams working on different branches, you are bound to run into merge conflicts since you would never pull down from 'develop' prior to pushing. It does not seem like best practice for the team pushing to try and resolve something they don't have much if any knowledge about.

One idea we had was doing a pull request on the 'develop' branch and having a team dedicated to resolving those.

Are they any options we are missing?

Answer 1

The idea behind feature branches is they should only contain a small, atomic change. This change should, in theory not cause merge conflicts due to its very nature.

If a feature is introducing merge conflicts I would be more inclined to examine what you consider to be "a feature".

The way I have experienced this being introduced is that a feature relates to a specific task which (in terms of time) should last no more than one or two days.

Given this short timescale it is unlikely that merge conflicts will arise during the cycle but in the event that they do, say for instance when you have multiple teams working in the same area of a codebase, a level of communication is required to ensure that the conflicts are resolved in the correct manner.

There are different models you can apply to help you manage conflict resolution. We work on a horizontal slicing model in which if multiple teams need a change to be made in a particular area of the codebase it is assigned to the team whose project encompasses the whole of that given module. Your company may be more interested in a vertical slicing model in which case you're less likely to run into merge conflicts across teams.

No amount of tooling can beat conversation for conflict resolution. If you know that your changes are going to impact a file that someone else is working on, the best model to follow is a conversation.

In some situations this will not be ideal, the business might have other ideas about whose changes go out when but as long as every developer keeps their feature branch up to date with develop then the propensity for conflicts is greatly reduced.