I'm considering creating a new tool, but I wanted to find out if something like it already exists.
tl;dr: Looking to make or employ a service which scans a SCM repository with the explicit goal of early warning when ongoing work might lead to "Conflict hell".
The Pain:
Working with many collaborators on a monorepo, conflicts are not possible to detect until specific effort is made to merge together work.
Whether it is the master/main/develop branch that I'm conflicting with or another teammate's feature branch, I must take a premeditated action to attempt to merge in or rebase on the other changes in order to discover that a conflict exists.
The Traditional Solution:
Communicate closely and regularly with teammates to limit the amount of overlap. Just work on something else, if someone might be currently touching or about to touch that code.
The Proposed Solution:
A service that monitors the git repo and proactively determines conflicts between branches. Mechanically, this can be done by checking out one branch and attempting a merge or patch on the other or any other suitable way. Feature branches are associated with "owners". The master branch is a special case which has no owner. Heuristics are put in place to mark branches as inactive if their recent activity is older than some amount of time, and also if they have been squashed into master, so that only branches actively being worked on are checked. The number of conflict checks thus performed is quadratic on the number of active branches, so it should be a manageable amount of processing for a typical team size contributing to one repo.
What this service would provide, then, is a proactive and timely notification to the only people for whom the information is relevant: "Your work and your colleague's work are now currently conflicting, and here is the conflicting content". This will serve to catch the situations when your pre-planning has failed, but also it can serve as a supplement to planning. It can provide tactical feedback on how much toe-stepping has happened, allowing for timely correction.
One requirement for this to work well would be that each contributor has to commit and push regularly in order to benefit from this service. But that's short-selling it because it should still be plenty of good forwarning if you have a long running branch and a colleague all of a sudden pushes and merges a big change into master, getting notified at this point is still better than finding out about it only when you complete your work and make your own PR.
Another point I think is that if this works as well as I hope it could work, then it's possible that some aspects of development planning can be streamlined, saving some time and overhead from the development process. I would draw a parallel here to the Just-In-Time concept. Here, when you step on somebody's toes, it's caught (after the fact, unfortunately), but with a much smaller delay than usual, the delay is roughly until your next commit and push. I think if the concept pans out, it should also be possible to reduce the delay to move closer to a true Just-In-Time experience, editor integration will be required, though. Taken to its logical conclusion, an entire real-time collaboration layer would exist above git, integrated into the editor.
Does anyone else see the value of such a tool? I'm not seeing any downsides whatsoever, this can run as an independent service, and fire off emails based on readily available git user information. It would be zero-effort to set up from the perspective of participating team members. If this idea has merit, does such a tool already exist, so I could try it out? Or should I just try to make it? Thanks.
