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…

No I’m wondering, how often do you have to resolve (more or less complex) merge conflicts?

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

    • MagicShel@programming.dev
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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…

  • blind3rdeye@lemm.ee
    link
    fedilink
    arrow-up
    5
    ·
    1 year ago

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

  • TheCulturedOtaku@beehaw.org
    link
    fedilink
    arrow-up
    4
    ·
    1 year ago

    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 with git merge -X theirs origin/${HEAD} or git 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.

  • Kissaki@feddit.de
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 year ago

    In my team of four developers, very rarely.

    I may even be resolving more conflicts against my own changes in other branches or from splitting up changes in a branch than against others’ changes.

    When they occur, TortoiseGitMerge usually resolves them automatically.

  • Sinfaen@beehaw.org
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    1 year ago

    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

  • AggressivelyPassive@feddit.de
    link
    fedilink
    arrow-up
    3
    ·
    1 year ago

    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.

  • einval@lemmy.einval.net
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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.

  • l3mming@lemmy.fmhy.ml
    link
    fedilink
    arrow-up
    2
    ·
    edit-2
    1 year ago

    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 sensible way that keeps the unit tests working.

  • ffmike@beehaw.org
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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.

  • Beto@lemmy.studio
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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.

  • mdkcore@fedia.io
    link
    fedilink
    arrow-up
    2
    ·
    1 year ago

    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

  • Mike_@lemmy.ca
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    With ~10 people on the team, many products, and dozens of repositories that we maintain, rarely. Maybe a few times per month. In the two years I’ve been with this company, I haven’t run into a single merge conflict that wasn’t straightforward to sort out.

  • jmsw22@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    We’re a small team, so generally are able to divide up work so that we’re not treading on each others toes. If it does happen it’s usually because we’ve made some project wide change like retrofitting auditing or something.

    I’ve not heard of fugitive, I’ll have to check it out!

  • The Doctor@beehaw.org
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    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.

  • dark_stang@beehaw.org
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    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.