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

    I honestly don’t get why folks dislike rebase. I use it constantly, especially to squash commits so that my pull requests are a single commit that can be reverted easily.

    • Ferk@kbin.social
      link
      fedilink
      arrow-up
      10
      ·
      edit-2
      1 year ago

      It’s also kinda annoying to have a history full of “merge” commits polluting the commit messages and an entwined mix of parallel branches crossing each other at every merge all over the timeline. Rebasing makes things so much cleaner, keeping the branches separate until a proper merge is needed once the branch is ready.

    • yaaaaayPancakes@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Because rebase is fraught with peril, if you also push rebased branches upstream and someone else works off that branch.

      If you stick to the rule of only using rebase on local branches that have never been pushed upstream, it’s an awesome tool. If you don’t, you’re eventually going to cause someone to have a bad day.

      • bellsDoSing@lemm.ee
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        Yeah, basically anything that rewrites already pushed history and is then (force-) push is bound to create problems (unless it’s a solo dev only ever coding on a single device, who uses the remote repo as a mere backup solution).

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

          Yep. I work exclusively in forks, and all my work is done on my machine, rebased, squashed and then pushed to my fork for a PR. No commits from main are ever touched in my rebase. It’s such a clean workflow for me.