• andrew@lemmy.stuart.fun
    link
    fedilink
    English
    arrow-up
    53
    arrow-down
    1
    ·
    edit-2
    7 months ago

    Merge takes two commits and smooshes them together at their current state, and may require one commit to reconcile changes. Rebase takes a whole branch and moves it, as if you started working on it from a more recent base commit, and will ask you to reconcile changes as it replays history.

      • andrew@lemmy.stuart.fun
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Yeah, the image (not mine, but the best I found quickly) kinda shows a rebase+merge as the third image. As the other commenter mentioned, the new commit in the second image is the merge commit that would include any conflict resolutions.

      • Atemu@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew@lemmy.stuart.fun meant.

      • bort@sopuli.xyz
        link
        fedilink
        arrow-up
        2
        ·
        7 months ago

        why would rebasing a feature branch change main?

        the image does not update the feature branch. It merges the featurebranch into main with a regular old merge-commit on the main branch.

    • Crow@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      6
      ·
      7 months ago

      That’s pretty cool, might actually do that. Tho, we currently don’t use the history as much anyways, we’re just having a couple of small student projects with the biggest group being 6 people. I guess it’s more useful if you’re actually making a real product in a huge project that has a large team behind it

      • RecluseRamble@lemmy.dbzer0.com
        link
        fedilink
        arrow-up
        5
        ·
        edit-2
        7 months ago

        Just remember to not combine it with force push or you’re in for some chaos (rewriting history team members have already fetched is a big no-no).

          • expr@programming.dev
            link
            fedilink
            arrow-up
            3
            ·
            edit-2
            7 months ago

            Or, you know, on your own feature branch to clean up your own commits. It’s much, much better than constantly littering your branch’s history with useless merge commits from upstream, and it lets you craft a high-quality, logical commit history.

            • RecluseRamble@lemmy.dbzer0.com
              link
              fedilink
              arrow-up
              1
              ·
              7 months ago

              Of course it has its uses. I didn’t mention them because the guy just learned about rebase - it’s unlikely to be applied flawlessly from the start.

              • expr@programming.dev
                link
                fedilink
                arrow-up
                1
                ·
                7 months ago

                I was replying to the other comment, not yours. Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

                Rebasing is really not a big deal. It’s not actually hard to go back to where you were, especially if you’re using git rebase --interactive. For whatever reason people don’t seem to get that commits aren’t actually ever lost and it’s not that hard to point HEAD back to some previous commit.

                • RecluseRamble@lemmy.dbzer0.com
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  7 months ago

                  I was replying to the other comment, not yours.

                  I know. Answered anyway because I thought of the same thing as you.

                  Though there’s not really a way of using rebasing without force pushing unless it’s a no-op.

                  I like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge. It’s also not obvious to beginners since pull is defaulted to fetch+merge.

                  • expr@programming.dev
                    link
                    fedilink
                    arrow-up
                    1
                    ·
                    7 months ago

                    Ah gotcha.

                    like to rebase after fetching and before pushing. IMO that’s the most sensible way to use it even in teams that generally prefer merge.

                    What do you mean? Like not pushing at all until you’re making the MR? Because if the branch has ever been pushed before and you rebase, you’re gonna need to force push the branch to update it.

                    Personally I’m constantly rebasing (like many times a day) because I maintain a clean commit history as I develop (small changes to things I did previously get commits and are added to the relevant commit as a fixup during interactive rebasing). I also generally keep a draft MR up with my most recent work (pushing at end of day) so that I can have colleagues take a look at any point if I want to validate anything about the direction I’m taking before continuing further (and so CI can produce various artifacts for me).

                    It’s also not obvious to beginners since pull is defaulted to fetch+merge.

                    Yeah, pull should definitely be --ff-only by default and it’s very unfortunate it isn’t. Merging on pull is kind of insane behavior that no one actually wants.

            • Transtronaut@lemmy.blahaj.zone
              link
              fedilink
              arrow-up
              1
              ·
              7 months ago

              You can do all that without force push. Just make a new branch and do the cleanup before the first push there. Allowing force push just invites disaster from junior developers who don’t know what they’re doing. If you want to clean up after them, that’s your business, I guess.

              • expr@programming.dev
                link
                fedilink
                arrow-up
                1
                ·
                7 months ago

                That’s exactly the same thing. A branch is nothing more than a commit that you’ve given a name to. Whether that name is your original branch’s name or a new branch’s name is irrelevant. The commit would be the same either way.

                A junior cannot actually do any real damage or cause any actual issue. Even if they force push “over” previous work (which again, is just pointing their branch to a new commit that doesn’t include the previous work), that work is not lost and it’s trivial to point their branch to the good commit they had previously. It’s also a good learning opportunity. The only time you actually can lose work is if you throw away uncommitted changes, but force pushing or not is completely irrelevant for that.

          • zalgotext@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Force pushes are perfectly safe if you’re working on your own branch, and even if you’re sharing a branch, you can still force push to it as long as you inform and coordinate with whoever else is working on that branch.

      • ScreaminOctopus@sh.itjust.works
        link
        fedilink
        English
        arrow-up
        7
        arrow-down
        4
        ·
        7 months ago

        I wouldn’t recommend it. The Git documentation itself doesn’t recommend rebase for more than moving a few unpushed commits to the front of a branch you are updating. Using it by default instead of merge requires you to use --force-push as part of your workflow which can lead to confusing situations when multiple developers end up commiting to the same branch, and at worst can lead to catastrophic data loss. The only benefit is a cleaner history graph, which is rarely used anyway, and you can always make the history graph easier to read with a gui without incuring any of the problems of rebase.

        • surge_1@lemmy.world
          link
          fedilink
          arrow-up
          8
          arrow-down
          2
          ·
          7 months ago

          Bad take IMO,

          At 10+ YOE, I use rebase almost exclusively. Branch from main, rebase to clean up commit history before putting up a PR. If commits are curated properly you don’t run into conflicts very often. Branches really shouldn’t be shared too often anyway, and the ones that are should be write protected.

          Catastrophic data loss isn’t really possible either with git since it’s all preserved and you can git reflog even if you mess up.

          The meme is right. Git good

          • Croquette@sh.itjust.works
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            When rebasing, it applies the changes without the commit history?

            Does that mean that when you fast forward your main/dev branch and commit, you then add a single commit that encompasses every changes that were rebase?

            • expr@programming.dev
              link
              fedilink
              arrow-up
              2
              ·
              edit-2
              7 months ago

              No, there are no fast-forwards with rebasing. A rebase will take take the diff of each commit on your feature branch that has diverged from master and apply those each in turn, creating new commits for each one. The end result is that you have a linear history as though you had branched from master and made your commits just now.

              If you had branched like this:

              A -> B -> C (master)
                 \
                   \ -> D (feature)
              

              It would like this after merging master into your feature branch:

              A -> B -> C (master) ->   E (feature)
                \                                    /
                  \ -> D -------------------> /
              

              And it would like this if you instead rebased your feature branch onto master:

              A -> B -> C (master) -> D' (feature)
              

              This is why it’s called a “rebase”: the current state of master becomes the starting point or “base” for all of your subsequent commits. Assuming no conflicts, the diff between A and D is the same as the diff between A and D'.

          • AggressivelyPassive@feddit.de
            link
            fedilink
            arrow-up
            4
            arrow-down
            4
            ·
            7 months ago

            Years of experience don’t really matter here, that’s just call to authority, in this case yourself. You might as well be the worst git user ever after 20 years of usage, or the best after 2. We don’t know that.

            Anyway, what you’re saying basically requires a perfect world to be true. Feature branch flow is perfectly fine, but you do end up with merge conflicts constantly, unless you have cordoned off areas of the repo for certain users. Two people working on unrelated features, both change a signature of some helper/util method, merge conflict. Nothing serious, can be fixed in a minute, and rebasing or merging won’t help for either.

            Merge is perfectly fine. And arguing about which strategy to use is one of those autistic debates we as an industry seemingly love to have. It doesn’t matter, but you’ll find people screaming at each other about it. See Emacs vs. Vi. Same crap.

            • surge_1@lemmy.world
              link
              fedilink
              arrow-up
              3
              arrow-down
              3
              ·
              7 months ago

              Merge is fine, but not knowing both rebase and merge is dumb. And I guess I’ve been in a perfect world this whole time in huge technical orgs lol.

        • expr@programming.dev
          link
          fedilink
          arrow-up
          6
          arrow-down
          1
          ·
          7 months ago

          This a really bad take and fundamentally misunderstands rebasing.

          First off, developers should never be committing to the same branch. Each developer maintains their own branch. Work that needs to be tested together before merging to master belongs on a dedicated integration branch that each developer merges their respective features branches into. This is pretty standard stuff.

          You don’t use rebasing on shared branches, and no one arguing for rebasing is suggesting you do that. The only exception might be perhaps a dedicated release manager preparing a release or a merge of a long-running shared branch. But that is the kind of thing that’s communicated and coordinated.

          Rebasing is for a single developer working on a feature branch to produce a clean history of their own changes. Rebasing in this fashion doesn’t touch any commits other than the author’s. The purpose is to craft a high quality history that walks a reader through a proposed sequence of logical, coherent changes.

          Contrary to your claim, a clean history is incredibly valuable. There’s many tools in git that benefit significantly from clean, well-organizes commits. git bisect, git cherry-pick… Pretty much any command that wants to pluck commits from history for some reason. Or even stuff like git log -L or git blame are far more useful when the commit referenced is not some giant amalgamation of changes from all over the place.

          When working on a feature branch, if you’re merging upstream into your branch, you’re littering your history with pointless, noisy commits and making your MR harder to review, in addition to making your project’s history harder to understand and navigate.

    • Elise@beehaw.org
      link
      fedilink
      arrow-up
      5
      ·
      7 months ago

      I’m relatively new to git and rebase looks like a mess to me? Like it appears to be making duplicate commits and destroys the proper history?

      If you use rebase to get a more readable history, isn’t the issue the tool you use to view the history?

      I guess I have to try it out a few times to get it.

      • Ephera@lemmy.ml
        link
        fedilink
        arrow-up
        5
        ·
        7 months ago

        What you probably mean by duplicate commits is that it assigns new commit IDs to commits that have been rebased. If you had already pushed those commits, then git status will tell you that the remote branch and your local branch have diverged by as many commits as you rebased.

        Well, and what is the “proper history”? If your answer is “chronological”, then why so?
        For the rare times that it matters when exactly a commit was created, they’ve got a timestamp. But otherwise, the “proper history” is whatever you make the proper history. What matters is that the commits can be applied one after another, which a rebase ensures.

        When you’re working on a branch and you continuously rebase on the branch you want to eventually merge to, then the merged history will look as if you had checked out the target branch and just made your commits really quickly without anyone else committing anything in between.
        And whether you’ve done your commits really quickly or over the course of weeks, that really shouldn’t matter.

        What is really cool about (supposedly) making commits really quickly is that your history becomes linear and it tells a comprehensible story. It won’t be all kinds of unrelated changes mixed randomly chronologically, but rather related commits following one another.
        And of course, you also lose the merge-commits, which convey no valuable information of their own.

        • Atemu@lemmy.ml
          link
          fedilink
          arrow-up
          2
          ·
          7 months ago

          you also lose the merge-commits, which convey no valuable information of their own.

          In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.

          • someonesmall@lemmy.ml
            link
            fedilink
            arrow-up
            1
            ·
            7 months ago

            Agreed, you also lose the info about the resolved merge conflicts during the merge (which have been crucial a few times to me).

            • Ephera@lemmy.ml
              link
              fedilink
              English
              arrow-up
              1
              ·
              7 months ago

              Well, with a rebase workflow, there should be no merge conflicts during the final merge. That should always be a fast-forward.

              Of course, that’s because you shift those merge conflicts to occur earlier, during your regular rebases. But since they’re much smaller conflicts at a time, they’re much easier to resolve correctly, and will often be auto-resolved by Git.

              You’re still right, that if you’ve got a long-running feature branch, there’s a chance that a conflict resolution broke a feature that got developed early on, and that does become invisible. On the flip-side, though, the person working on that feature-branch has a chance to catch that breakage early on, before the merge happens.