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?
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.