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