• gandarf @midwest.social
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 year ago

    OK. Query.

    Rebase or merge into current?

    I personally never rebase. It always seems to have some problem. I’m surely there’s a place and time for rebasing but I’ve never seen it in action I guess.

    • dukk@programming.dev
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      Merge commits suck.

      My biggest issue with GitHub is that it always squashes and merges. It’s really annoying as it not only takes away from commit history, but it also puts the fork out of sync with the main branch, and I’ll often realize this after having implemented another features, forcing me end up cherry picking just to fix it. Luckily LazyGit makes this process pretty painless, but still.

      Seriously people, use FF-merge where you can.

      Then again, if my feature branch has simply gone behind upstream, I usually pull and rebase. If you’ve got good commits, it’s a really simple process and saves me a lot of future headaches.

      There’s obviously places not to use rebase(like when multiple people are working on a branch), but I consider it good practice to always rebase before merge. This way, we can always just FF-merge and avoid screwing with the Git history. We do this at my company and honestly, as long as you follow good practices, it should never really get too out of hand.

      • GigglyBobble@kbin.social
        link
        fedilink
        arrow-up
        0
        ·
        1 year ago

        Merge commits suck.

        My biggest issue with GitHub is that it always squashes and merges.

        You are aware you’re talking about two different pieces of software?

        • dukk@programming.dev
          link
          fedilink
          arrow-up
          1
          ·
          1 year ago

          Yeah, I am. However GitHub, being the biggest Git hosting provider and all that, makes you use merge commits. FF-merges must be done manually from the command line. While this definitely isn’t a problem for me, many people out there just don’t care and merge without a second thought (which, as I said in my comment, results in having to create a new branch and cherry picking the commits onto there).

    • Throwaway@lemm.ee
      link
      fedilink
      arrow-up
      0
      ·
      1 year ago

      What you do is create a third branch off master, cherry pick the commits from the feature branch, and merge in the third branch. So much easier.

      • GigglyBobble@kbin.social
        link
        fedilink
        arrow-up
        1
        ·
        1 year ago

        If your cherry-pick doesn’t run into conflicts why would your merge? You don’t need to merge to master until you’re done but you should merge from master to your feature branch regularly to keep it updated.

        • atyaz@reddthat.com
          link
          fedilink
          arrow-up
          0
          ·
          1 year ago

          That is absolutely not what rebasing does. Rebasing rewrites the commit history, cherry picking commits then doing a normal merge does not rewrite any history.

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

            I’m sorry but that’s incorrect. “Rewriting the commit history” is not possible in git, since commits are immutable. What rebase actually does is reapply each commit between upstream and head on top of upstream, and then reset the current branch to the last commit applied (This is by default, assuming no interactive rebase and other advanced uses). But don’t take my word for it, just read the manual. https://git-scm.com/docs/git-rebase

            • atyaz@reddthat.com
              link
              fedilink
              arrow-up
              0
              ·
              1 year ago

              “Reapply” is rewriting it on the other branch. The branch you are rebasing to now has a one or multiple commits that do not represent real history. Only the very last commit on the branch is actually what the user rebasing has on their computer.

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

                Cherry picking also rewrites the commits. This is equivalent to rebasing:

                git branch -f orig_head
                git reset target
                git cherry-pick ..orig_head
                
          • yogo@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            1 year ago

            Have you tried interactive rebase (rebase -i)? I find it very useful

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

                rerere is a lifesaver here.

                (I’m also a fan of rebasing; but I also like to land commits that perform a logical and separable chunk of work, because I like history to have decent narrative flow.)

  • GigglyBobble@kbin.social
    link
    fedilink
    arrow-up
    0
    ·
    1 year ago

    I usually merge because I like to see commit history as it happened and because rebasing multiple commits with conflicts is more time-consuming than fixing it in one merge commit.

    I do rebase smaller changes though to reduce merge commit clutter and like interactive rebase to clean up my local commit mess before pushing.

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

      I create a new branch locally with git switch --create, pull everything from main, sacrifice a small squirrel, and run the project to make sure everything still works.

      If something doesn’t work or I can’t figure out how to resolve conflicts, I quietly switch back to my previous branch like nothing happened. That problem is for future me.