• Margot Robbie@lemm.ee
    link
    fedilink
    arrow-up
    4
    ·
    6 months ago

    I think this is a fake quote that somebody made up for an Internet comedy bit, since it seems unlikely for Hollywood actress Sydney Sweeney to have such uncharacteristically strong opinion on software version control, of all things.

    Because she of all people would know that there isn’t anything wrong with using git merge, and it ultimately comes down to personal preference to what you are used to.

      • CmdrKeen@lemmy.today
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        No doubt. git rebase is like a very sharp knife. In the right hands, it can accomplish great things, but in the wrong hands, it can also spell disaster.

        As someone who HAS used it a fair amount, I generally don’t even recommend it to people unless they’re already VERY comfortable with the rest of git and ideally have some sense of how it works internally.

        • expr@programming.dev
          link
          fedilink
          arrow-up
          0
          ·
          6 months ago

          Yeah it is something people should take time to learn. I do think its “dangers” are pretty overstated, though, especially if you always do git rebase --interactive, since if anything goes wrong, you can easily get out with git rebase --abort.

          In general there’s a pretty weird fear that you can fuck up git to the point at which you can’t recover. Basically the only time that’s really actually true is if you somehow lose uncommitted work in your working tree. But if you’ve actually committed everything (and you should always commit everything before trying any destructive operations), you can pretty much always get back to where you were. Commits are never actually lost.

          • thanks_shakey_snake@lemmy.ca
            link
            fedilink
            arrow-up
            1
            ·
            6 months ago

            You can get in some pretty serious messes, though. Any workflow that involves force-pushing or rebasing has the potential for data loss… Either in a literally destructive way, or in a “Seriously my keys must be somewhere but I have no idea where” kind of way.

            When most people talk about rebase (for example) being reversible, what they’re usually saying is “you can always reverse the operation in the reflog.” Well yes, but the reflog is local, so if Alice messes something up with her rebase-force-push and realizes she destroyed some of Bob’s changes, Alice can’t recover Bob’s changes from her machine-- She needs to collaborate with Bob to recover them.

            • expr@programming.dev
              link
              fedilink
              arrow-up
              0
              ·
              6 months ago

              Pretty much everything that can act as a git remote (GitHub, gitlab, etc.) records the activity on a branch and makes it easy to see what the commit sha was before a force push.

              But it’s a pretty moot point since no one that argues in favor of rebasing is suggesting you use it on shared branches. That’s not what it’s for. It’s for your own feature branches as you work, in which case there is indeed very little risk of any kind of loss.

              • thanks_shakey_snake@lemmy.ca
                link
                fedilink
                arrow-up
                1
                ·
                6 months ago

                Ah, you’ve never worked somewhere where people regularly rebase and force-push to master. Lucky :)

                I have no issue with rebasing on a local branch that no other repository knows about yet. I think that’s great. As soon as the code leaves local though, things proceed at least to “exercise caution.” If the branch is actively shared (like master, or a release branch if that’s a thing, or a branch where people are collaborating), IMO rebasing is more of a footgun than it’s worth.

                You can mitigate that with good processes and well-informed engineers, but that’s kinda true of all sorts of dubious ideas.

                • expr@programming.dev
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  6 months ago

                  Pushing to master in general is disabled by policy on the forge itself at every place I’ve worked. That’s pretty standard practice. There’s no good reason to leave the ability to push to master on.

                  There’s no reason to avoid force pushing a rebased version of your local feature branch to the remote version of your feature branch, since no one else should be touching that branch. I literally do this at least once a day, sometimes more. It’s a good practice that empowers you to craft a high-quality set of commits before merging into master. Doing this avoids the countless garbage fix typo commits (and spurious merge commits) that you’d have otherwise, making both reviews easier and giving you a higher-quality, more useful history after merge.

              • aubeynarf@lemmynsfw.com
                link
                fedilink
                arrow-up
                1
                ·
                edit-2
                4 months ago

                If “we work in a way that only one person can commit to a feature”, you may be missing the point of collaborative distributed development.

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

                  No, you divide work so that the majority of it can be done in isolation and in parallel. Testing components together, if necessary, is done on integration branches as needed (which you don’t rebase, of course). Branches and MRs should be small and short-lived with merges into master happening frequently. Collaboration largely occurs through developers frequently branching off a shared main branch that gets continuously updated.

                  Trunk-based development is the industry-standard practice at this point, and for good reason. It’s friendlier for CI/CD and devops, allows changes to be tested in isolation before merging, and so on.

  • Croquette@sh.itjust.works
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    I know this is a meme post, but can someone succinctly explain rebase vs merge?

    I am an amateur trying to learn my tool.

    • jaemo@sh.itjust.works
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      Merge keeps the original timeline. Your commits go in along with anything else that happened relative to the branch you based your work off (probably main). This generates a merge commit.

      Rebase will replay all the commits that happened while you were doing your work before your commits happen, and then put yours at the HEAD, so that they are the most recent commits. You have to mitigate any conflicts that impact the same files as these commits are replayed, if any conflicts arise. These are resolved the same way any merge conflict is. There is no frivolous merge commit in this scenario.

      TlDR; End result, everything that happened to the branch minus your work, happens. Then your stuff happens after. Much tidy and clean.

      • Croquette@sh.itjust.works
        link
        fedilink
        arrow-up
        0
        ·
        6 months ago

        Thanks for the explanation. It makes sense. To my untrained eyes, it feels like both merge and rebase have their use. I will try to keep that in mind.

        • aubeynarf@lemmynsfw.com
          link
          fedilink
          arrow-up
          1
          ·
          5 months ago

          Never use rebase for any branch that has left your machine (been pushed) and which another entity may have a local copy of (especially if that entity may have committed edits to it).

    • letsgo@lemm.ee
      link
      fedilink
      arrow-up
      0
      arrow-down
      1
      ·
      6 months ago

      Merge gives an accurate view of the history but tends to be “cluttered” with multiple lines and merge commits. Rebase cleans that up and gives you a simple A->B->C view.

      Personally I prefer merge because when I’m tracking down a bug and narrow it down to a specific commit, I get to see what change was made in what context. With rebase commits that change is in there, but it’s out of context and cluttered up with zillions of other changes from the inherent merges and squashes that are included in that commit, making it harder to see what was changed and why. The same cluttered history is still in there but it’s included in the commits instead of existing separately outside the commits.

      I honestly can’t see the point of a rebased A->B->C history because (a) it’s inaccurate and (b) it makes debugging harder. Maybe I’m missing some major benefit? I’m willing to learn.

  • Cyborganism@lemmy.ca
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 months 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
      0
      ·
      6 months 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.

      • AggressivelyPassive@feddit.de
        link
        fedilink
        arrow-up
        1
        ·
        6 months ago

        Honestly, I’m pretty sure 99.9% of git users never really bother with the git history in any way that would be hindered by merging.

        Git has a ton of powerful features, but for most projects they don’t matter at all. You want a distributed consensus, that’s it. Bothering yourself with all those advanced features and trying to learn some esoteric commands is frankly just overhead. Yes, you can solve great problems with them, but these problems almost never occur, and if they do, using the stupid tools is faster overall.

    • magic_lobster_party@kbin.run
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      How others are keeping their branches up to date is their problem. If you use Gitlab you can set up squash policy for merge requests. All the abomination they’ve caused in their branch will turn into one nice commit to the main branch.

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

        I don’t want squashed commits. It makes git tools worse (git bisect, git cherry-pick, etc.) and I work very hard to craft a meaningful set of commits for my work and I don’t want to throw all of that away.

        But yeah, I don’t actually give a shit what they are doing on their branches. I regularly rebase onto master anyway.