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?
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
Rarely. Require linear history for the win.
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.
This can occur on a growing/evolving team/application due to live refactors. Especially if the mission is open ended, and it has to keep up with features from other applications in the same domain.
We practice pain driven development, and with little resourcing we have to get things as right as possible as soon as we see a growing problem. Stomp down the tech debt often, and it doesn’t come back to bite us. Direction changes happen often, being prepared to adjust quickly is critical to success (seriously, it’s almost harrowing, if you’re not ahead you may be unworkably behind)
For an application that’s expected to move quickly, LOTS of little and large refactors happen all the time. Which inevitably means merge conflicts, especially if someone is designing for a new or changing problem space that touches a lot of existing parts.
For us, we probably deal with ugly conflicts every other week, and trivial ones weekly.
It’s not always that way ofc, but when there are multiple applications upstream and downstream that rely on what your building, and upstream is moving fast, you have to keep up to avoid downstream breakages. Even moreso when it’s data-focused, not feature focused.
