I basically only use git merge like Theo from T3 stack. git rebase rewrites your commit history, so I feel there’s too much risk to rewriting something you didn’t intend to. With merge, every commit is a real state the code was in.

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

    The cases where you can use git pull --rebase have high overlap with the cases where git rebase is sane.

    The important thing is when to avoid doing git push --force (almost always; if your remote is a personal fork you theoretically could just create an infinite number of similar branch names for your rebases). Though there are edge cases involving local/SSH clones.

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

      What does git pull rebase do? If I understand it correctly, it pulls in the remote changes but rebases your changes to be on top of them, instead of merging the remote and local branch? What is the intended usage of it, it sounds like a lot better way how to pull, why not to use it as default pull?

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

        you pretty much should use it as the default pull. There are very few cases when you shouldn’t use it. Something like fetching from an upstream remote maybe.

      • GitProphet@lemmy.sdf.org
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        Because rebasing changes the history, which would mess with other people’s copies of the same branch, wherefore it shouldn’t be default.