The product being discussed here doesn't solve the issue of merge conflicts itself, but rather of eventual consistency. Merge conflicts is only a part of it, and there are some heuristics that can be used to reduce those, but eventually require manual review. Perhaps with Github Copilot this can improve?
I found it a bit frustrating that merge tools I used were never able to solve trivial merge conflicts automatically. So I built something myself: https://fdietze.github.io/blend
On that page you can paste your merge conflict and copy the automatically merged result, along with some useful diffs. I hope it helps someone else. So far it solves around 80% of my conflicts automatically.
Merge conflict resolution seems like something incredibly obvious to have, that yet is a pretty unique feature for the web UI. I've done a lot of stuff with GitHub's web UI, and I pretty much hit a wall any time I do something that's going to create a merge conflict, since I never really bothered to learn Git CLI. I saw GitBook did something similar to this a while ago, but that's for books, not code.
While tools like Github check for patch conflicts, they don't check for semantic conflicts (e.g. one PR adds a new use of a function another PR removes).
This is where merge queues come into play which have a variety of names (merge queue, submit queue, merge train, etc)
I have a write up on merge queues [0] that goes into other benefits (e.g. speeding up PR builds), design considerations and their trade offs, and a comparison of various implementations.
Do you know what github does differently when performing a merge? I’ve noticed sometimes github says there’s a merge conflict yet when i do the merge locally using the default recursive strategy it often just merges without any conflicts. I know there are cases it can’t handle when there are conflicts, but it seems odd that it cannot merge when there are no merge conflicts.
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
I honestly don't encounter non-trivial merge conflicts in practice on a team of 5 developers. Our repos are scoped roughly to be team-sized so the velocity is low enough to know what everyone is working on.
I guess some of this advice applies better to repos where a large number of people are working on it.
I couldn't imagine giving up the quality gate factor of PRs. Carving out the time to dissect changes catches so many bugs (although it can be received harshly sometimes compared to face to face).
Also pushing to master vs. long lived feature braches is a false dichotomy. You can have small PRs on short-lived branches that may not be a complete feature but can be merged without making the main branch unreleasable.
There is also the political factor to consider in companies where product and sales people control the selected work items. Once something is in a working state there is pressure to move on to the next thing. Fighting for quality before it is in a publishable state is a devs best defence against later rework.
The CD community is overly obsessed with velocity. Of course removing obstacles can lead to a smoother faster workflow. Take it to the extreme and it becomes a dopamine hit activity, the goal is to merge changes fast and we become unable to take the time to think deeply and reflect since it is clear that we are valued by our rate of commits over smart decisions.
Super interesting. I saw you mentioned the headaches that came with merge requests. Did you having the same problem with separate prod, staging, test, and dev repos via a forking git workflow?
I hope someone solves the merge conflict problem once and for all. Each time there’s a merge conflict the project stops for days as no one knows how to resolve them. In the end the solution always is to delete the git repository and clone it again.
An example of the problem we are describing is explained here: https://blog.mergequeue.com/managing-github-merges-for-high-...
reply