• dohpaz42@lemmy.world
    link
    fedilink
    English
    arrow-up
    3
    ·
    2 months ago

    In my experience, this amount of conflicts typically occurs because 1) most people mass commit a bunch of (mostly unrelated) changes at once, which leads to 2) inexperienced/impatient devs to clobber incoming merge conflicts without doing proper merges (mostly because they can’t make heads or tails of the diffs).

    This is very easily mitigated if all developers would make small, related commits (with descriptive commit messages and not “committing changes”). This makes everybody’s life easier because 1) diffs are smaller and readable for conflicts, 2) the dev can see the progression of code through commit history, 3) broken code is more easily revertable (and traceable) if something goes wrong, and 4) it’s easier to cherry pick specific changes if the whole changes cannot be published all at once.

    Also, git pull --rebase is your friend and not scary at all. It applies all incoming changes first, then applies your new commits last. 9 out of 10 times it avoids conflicts.

    Lastly, use a GUI. There are plenty out there to suit your tastes, and I feel they are a safer and easier alternative than CLI. Some GUIs are very safe and even allow undo operations on most things.

    • PotatoesFall@discuss.tchncs.de
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      not scary at all

      I have seen some juniors really shoot themselves in the foot with rebasing, and I’ve been there as well before. I agree it can be useful, but it definitely requires understanding of what is going on :P

      • dohpaz42@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        2 months ago

        What I suggest is not the same as using git rebase. It’s pretty automatic and easily abortable.