Recently I’ve experienced a significant increase in merge conflicts at the company I’m currently working at (we hired a couple of junior data scientists and some are not that familiar with git)
Even though those merge conflicts can be a little tedious to resolve, I realized that I personally started to enjoy it - especially using fugitive. Haven’t had many conflicts in a while, so almost forgot about Gdiffsplit and how awesome that plugin is…
Now I’m wondering, how often do you have to resolve (more or less complex) merge conflicts?
Honestly, almost never. That’s why there are daily meetings, so that you don’t change the same code at the same time.
This made me realize why I found this whole question so confusing. I write code professionally, but don’t really do open-source professionally or personally. There’s just very little reason for two people to be writing code in the same file in the same week in my job. If it does happen, it still doesn’t usually come close enough to cause a conflict. The rare case I find myself resolving merge conflicts is usually because I have some super old stash that I decide I actually want to apply months later.
Also having issues, pull requests, Projects and so on to organize work.
Are you suggesting you don’t throw 5 developers simultaneously onto a new project with poorly defined and understood requirements and tell them to just get their story done whatever it takes? Because let me tell you, that is a recipe for merge conflicts…
Fairly often.
I tend to fork open-source stuff when I want to make my own adjustments, often the adjustments I make are not wanted upstream. So I’m doomed to having merge conflicts for all eternity.
Often what happens though is that I fix some bug, and then a few months later the upstream fixes it in some other way - so the conflict resolution is to basically just throw away my own (clearly superior but now obsolete*) changes, to avoid more conflicts later on.
(* I’m joking. But it does feel bad to throw away good work.)
It generally happens often without pre-planning and modularizing sections of developed code (even harder with data science, given the often functional nature of data science code bases). But when it does happen, it doesn’t have to be aweful.
To resolve, I generally just create a safe local branch to temporarily complete the merge in that I created form my local copy, and then I pull in the remote copy that I want to merge in with mine using
git merge -X theirs ${THEIR_BRANCH_NAME}, which favors their remote changes over yours (I assume origin is more correct than me). Then, conflicts will arise, and you manually perform diffs and checkin the final version with conflicts resolved as a new commit locally. Once complete, it is generally safe to push that temp branch to the remote or your fork for a Pull Request submission, or you may merge the temp branch with the conflict resolves into your running branch. Either way, before the PR, make sure to run tests with the integrated changes first, and to pull merged remote afterwards to fast forward your running copy (such as withgit merge -X theirs origin/${HEAD}orgit pull origin/${HEAD}Best answer though: pre plan your code base to include some modularity so that 2 people aren’t actively working on the same file at once, encourage daily check-ins to remotes and daily pulls, and ensure that headless unit tests are in place for critical areas, such as logic and boundary cases, at minimum (and that those run in CI/CD). +1 if you use uniform docker tooling to ensure all environments, even local, are the same. And another +1 if you have good telemetry based on APM metrics and traces for after code is integrated.
Occasionally I’ll get hit with a few unwieldy conflicts. Usually it’s one or two lines, and always a whitespace issue because someone’s code style just has to be different.
My team practices rebasing instead of merging, but generally our tasks are pretty separate so conflicts are uncommon. The ones that we do have are not that big.
However I am anticipating more of them now that we’re changing build systems
In my team of four developers, very rarely.
I may even be resolving more conflicts against my own changes in other branches than against others changes.> Gdiffsplit
When they occur, TortoiseGitMerge usually resolves them automatically.
we are experiencing some conflicts now that some new coworkers started in the company, they are getting used to our workflow
but normally they are quite rare to happen here
Very rarely. But I organize my code in ways that avoid it. Ex: if I make an API project, I make one router that dynamically forwards the request to the designated handler rather than registering every route in one file.
Quite often, mostly because the project is rather huddled and some devs refuse to use proper tools and often cause unwanted whitespace changes.
Yes, we did talk about it, but if the principal architect thinks that autoformat is at least as evil as proper documentation, it just won’t happen for him.
Your principal architect sounds like an idiot.
I have to resolve them way more than I should. We have internal devs and external devs and there is a lot of treading on toes. For any conflict that isn’t super obvious (90% are) I just ask the two devs involved to resolve it together in a way that keeps the unit tests working.
Rarely. Require linear history for the win.
I work on a big open source project with hundreds of committers, so quite often — I’d say a few times a week, maybe a third of my PRs.
Depended on the size of the team in my experience. With a project of ~50 devs split into 10 teams, I was having to resolve conflicts perhaps every other PR. But training and standards for workflow can certainly help.
I’m a hobby dev (for now), and work almost exclusively by myself so very rarely.
At work, very rarely so far. I think I’ve run into my first merge conflict in six or seven years last week.
At home, quite often with Part-DB-symfony, largely because of the composer.lock file.
