Git – How to Minimize Merge Conflicts When Using Non-Lock VCS

development-processgitversion control

I have been using git for about four months now. While I like most of its features, I find it rather inconvenient that multiple developers can make concurrent changes to the same file and then a need for merging ensues. In fact, I would prefer waiting for a file to get unlocked over tedious and brain hurting merges.

I was wondering if there was a team etiquette or workflow to circumvent this terrible predicament. In my ideal world of development, there would never be a need to merge. E.g. is there a combination of hooks, commands, and workflows for git in order to have a remote repository notified when a local repository changes a file so that other developers get a git notification if they themselves try to modify the same file concurrently (e.g. when they run git status or something like that)?

Best Answer

In an ideal world, merge conflicts never happen. There are certain scenarios where merge conflicts are more common... So my advice to you would be avoid these scenarios. And here they are.

Tightly coupled concerns

Let's say you have a front-end engineer and a back-end engineer. And you run into conflicts. This is usually because your code is not architected such that the two parts can evolve without interrupting each other, like mixing database access with templating. You get around this by introducing just enough abstraction to add distance between the two concerns.

API changes and concurrent feature development

Let's say I'm adding a small feature to my product, and it is orthogonal to the innards. It will be a point release. Meanwhile, the lead architect is refactoring the guts of the product to bring it from 1.0 to 2.0. I'm expecting 1.0 to 1.1 for the release of my feature.

Here, the architect will be touching a lot of surface area. And if you don't have another layer of abstraction between your feature and the raw API, you will run into a very messy conflict.

Sometimes in large organizations this cannot be helped.

Overly aggressive refactoring

This is actually the same as API changes. Even though there are no functional changes, there lots of textual changes, and from Git's perspective, that is the same.

Remedies

  • Keep changes physically small. Small diffs, small amount of lines changed
  • Release to master frequently
  • Integrate master frequently
  • Communicate about disruptive changes (like API changes/large refactors)
  • Separate business concerns across "physical" boundaries (modules/files/repos)
Related Topic