• Cyborganism@lemmy.ca
    link
    fedilink
    arrow-up
    46
    arrow-down
    1
    ·
    edit-2
    2 years ago

    I prefer to rebase as well. But when you’re working with a team of amateurs who don’t know how to use a VCS properly and never update their branc with the parent branch, you end up with lots of conflicts.

    I find that for managing conflicts, rebase is very difficult as you have to resolve conflicts for every commit. You can either use rerere to repeat the conflict resolution automatically, or you can squash everything. But when you’re dealing with a team of Git-illiterate developers (which is VERY often the case) you can either spend the time to educate them and still risk having problems because they don’t give a shit, or you can just do a regular merge and go on with your life.

    Those are my two cents, speaking from experience.

    • TechNom (nobody)@programming.dev
      link
      fedilink
      English
      arrow-up
      15
      arrow-down
      1
      ·
      2 years ago

      I agree that merge is the easier strategy with amateurs. By amateurs I mean those who cannot be bothered to learn about rebase. But what you really lose there is a nice commit history. It’s good to have, even if your primary strategy is merging. And people tend to create horrendous commit histories when they don’t know how to edit them.