• Korne127@lemmy.world
    link
    fedilink
    English
    arrow-up
    18
    ·
    1 year ago

    Merge conflict in general is fine

    What’s really bad is if someone drastically changed the implementation of something which you’ve also changed and if you completely need to rework it…

    • RedditWanderer@lemmy.world
      link
      fedilink
      English
      arrow-up
      31
      ·
      1 year ago

      What’s really bad is if someone drastically changed the implementation of something which you’ve also changed

      That’s not a merge conflict, that’s a management conflict.

      • Korne127@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        Oh, I mean I was talking about Open Source projects. If you just work privately and don’t say at some kind of central place (like a Discord or Matrix server) on what you’re working on, then it can easily happen that just two people do that at the same time without knowing of each other.

  • Knusper@feddit.de
    link
    fedilink
    English
    arrow-up
    9
    arrow-down
    1
    ·
    edit-2
    1 year ago

    Merge early and merge often.

    And ideally, each commit represents a working state of your software. If your team is disciplined enough with that, you can save yourself the feature branches and merges.

    • yggdar@lemmy.wtf
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      Are you expecting a developer to test everything every time they commit? Thoroughly testing even a small application or feature subset will take up quite a bit of time. You also want devs to commit often, so it is easy to roll back an approach that didn’t pan out, or just to go back and figure out what change caused something to stop working. If you end up committing only a few times per week because everything needs to be thoroughly tested, I’m not convinced it is a good approach.

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

        No, they should not need to test everything, but this strongly depends on your code quality and project setup.
        There’s definitely other paths to the goal, but generally for larger projects, I recommend:

        • Good isolation between components. A change in one component should not have unforeseeable effects in other components.

        • Automatic unit tests for each component, so devs can test their changes in isolation.

        • A statically typed, compiled language, so that compiling does a basic integration check between components.

        • Strong ties between components, where it makes sense. For example, ideally, the communication model between backend and frontend is in a shared module/library, so that if someone does change the model, it leads to compile errors on both sides.

        • Automatic integration tests + a CI/CD pipeline, which tests the rest of the application after each push. This will let you know as early as possible, if you did push a broken commit.

        • A multi-project build with all parts of your application in a monolithic repo, so that all components get continuously compiled + integrated with their most recent changes.

        This rigidity does have challenges of its own.
        For example, a change in the backend might force a change in the communication model and therefore in the frontend, too. And if you’re exclusively backend, you might struggle with updating the frontend accordingly.
        Then you’ll need to push onto a separate branch and look at it with your frontend colleague later. But hopefully, you get that arranged within a day or two, so the merge conflicts should still be quite tame.

        And obviously, this rigidity has tons of advantages. Not needing to wonder whether frontend and backend, or any other interface, is compatible right now, is just insanely good.

  • The Cuuuuube@beehaw.org
    link
    fedilink
    English
    arrow-up
    8
    ·
    1 year ago

    git rebase -x theirs origin/main and then look at the lines your changing to see what needs to be retouched

  • abbadon420@lemm.ee
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 year ago

    It’s the same with my colleagues as with my wife. It’s always a race who comes first.

  • dontblink
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    Had to deal with that this morning, my god what does git want me to do

  • JadenSmith@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    2
    ·
    1 year ago

    I’ve got one more! I get stress based tension headaches, which represent as migraine symptoms!

    Memes help tho.