• Margot Robbie@lemm.ee
    1785·
    2 years 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.

    • Artyom@lemm.ee
      471·
      2 years ago

      Margot Robbie, I was about to agree with you and thought that was a very reasonable take, until you tried to argue that git merge is better than git rebase, then I simply had to disregard the whole thing.

    • Jax@sh.itjust.works
      23·
      2 years ago

      But esteemed Academy Award nominated character actress and film director, Margot Robbie, if it’s unlikely that Hollywood actress Sydney Sweeney said this… wouldn’t it be just as unlikely that Margot Robbie would be here? Adding her own comment?

      … are you projecting? Is there something you want to tell us esteemed Academy Award nominated character actress and film director Margot Robbie?

    • hactar42@lemmy.world
      8·
      2 years ago

      I think this is a fake quote that somebody made up for an Internet comedy bit

      You can tell by the pixels

  • Cyborganism@lemmy.ca
    461·
    2 years 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.devEnglish
      151·
      2 years 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.

  • tengkuizdihar@programming.dev
    35·
    2 years ago

    Please for the love of god don’t use merge, especially in a crowded repository. Don’t be me and suffer the consequences. I mistakenly mention every person with a commit between the time I created the branch until current master.

    • oortjunk@sh.itjust.works
      9·
      2 years ago

      Could have been worse. I mean, like, imagine of you were using like CVS and you put a watch on the root! Haha and then like every trivial commit in the repo caused everyone to in the entire org to get an email and it crashed the email servers.

      Like who’d even DO that?! Though, I bet if you met that guy he’d be ok. Like not a jerk, and pretty sorry for all those emails. A cool guy.

      • tengkuizdihar@programming.dev
        3·
        2 years ago

        really? how come? I thought they are mentioned because of the diffs if compared to master, which merge basically just… merge on top of my branch (?)

        • Atemu@lemmy.ml
          2·
          2 years ago

          They were mentioned because a file they are the code owner of was modified in the PR.

          The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).

          If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.

          • Bourff@lemmy.world
            12·
            2 years ago

            Just for the record, I think you’re conflating git and GitHub. They are not the same thing, even if GH would like you to think so.

    • droans@lemmy.world
      2·
      2 years ago

      You sent over twenty-two thousand notifications lmao.

      And then the bot added about as many tags to the PR.

    • BlackPenguins@lemmy.world
      17·
      2 years ago

      Merge is taking all the code from the master branch and combining it with the task branch, resulting in a commit for just the merge itself.

      Rebase is “re-basing” where your task branch was created from off the master branch. It essentially takes all the commits from master that happened since you branched, REWRITES THE HISTORY of your task branch by inserting those master branch commits before all your existing commits, and effectively makes your task branch look like it was branched yesterday instead of like 4 weeks ago. You changed where your task branch originated on the master. You moved its base.

      Atlassian does a fantastic writeup on this.

        • BlackPenguins@lemmy.world
          6·
          2 years ago

          Kind of. Both merge and rebase result in the branches “synced up” but they do it in different ways.

          Merge is making a batter for cookies, having a bowl for dry ingredients (task branch) and a bowl for wet ingredients, (master branch) making them separately and then just dumping the dry bowl into the wet bowl (merge).

          Rebase is taking a time machine back to before you started mixing the dry ingredients, mix all the wet ingredients first then add the dry ones on top of that in the same bowl.

          It’s really hard to create an analogy for this.

      • Crow@lemmy.blahaj.zone
        1·
        2 years ago

        So, with a merge you basically shuffle in the changes from both branches, but a rebase takes only the changes from one branch and puts it over the other? Edit: no. Read wrong. I should probably watch a vid about it or something

  • jjjalljs@ttrpg.network
    13·
    2 years ago

    I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.

    All the garbage “spelled thing wrong” and “ran formatter” commits go away. Main is clean and linear.

      • jjjalljs@ttrpg.network
        4·
        2 years ago

        …and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.

        You then rebase so you have a nice linear history with no weird merge commits hanging around.

        • GissaMittJobb@lemmy.ml
          1·
          2 years ago

          You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up

          The next step on the Git-journey is to use interactive rebasing in order to never push these commits in the first place and maintain a clean history to be consumed by the code reviewer.

          Squashing is still nice in order to have a one-to-one relationship between commits on the main branch to pull requests merged, imo.

        • cobra89@beehaw.org
          1·
          2 years ago

          Okay honest question, when you merge a PR in GitHub and choose the squash commits box is that “rebasing”? Or is that just squashing? Because it seems that achieves the same thing you’re talking about.

          • jjjalljs@ttrpg.network
            2·
            2 years ago

            There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.

            Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch

            Rebase takes your commit(s) and sticks them on the end.

            Merge does something else I don’t understand as well, and makes a merge commit.

            Also there was an earthquake in NYC when I was writing this. We may have angered the gods.

            • Atemu@lemmy.ml
              1·
              2 years ago

              You should IMO always do this when putting your work on a shared branch

              No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.

              Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
              If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.

              Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.

              • jjjalljs@ttrpg.network
                1·
                2 years ago

                I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.

                Do you?

                Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.

                • Atemu@lemmy.ml
                  1·
                  2 years ago

                  Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.

            • cobra89@beehaw.org
              1·
              2 years ago

              Lmao I’m in the NYC area and my whole house shook. I’m right there with you. Thanks for the explanation!

      • swordsmanluke@programming.dev
        16·
        2 years ago

        Argh. I hate that argument.

        Yes - “Rewriting history” is a Bad Thing - but o argue that’s only on ‘main’ (or other shared branches). You should (IMHO) absolutely rewrite your local history pre-push for exactly the reasons you state.

        If you rewrite main’s history and force your changes everybody else is gonna have conflicts. Also - history is important for certain debugging and investigation. Don’t be that guy.

        Before you push though… rebasing your work to be easily digestible and have a single(ish) focus per commit is so helpful.

        • review is easier since concerns aren’t mixed
        • If a commit needs to be reverted it limits the collateral damage
        • history is easier to follow because the commits tell a story

        I use a stacked commit tool to help automate rebasing on upstream commits, but you can do it all with git pretty easily.

        Anyway. Good on you; Keep the faith; etc etc. :)

        • thesmokingman@programming.dev
          4·
          2 years ago

          The only other time rewriting history might be bad is when you’re working on a shared branch, which is the point of not rewriting main. If you are working solo on a branch, its history is only what you merge into main so it doesn’t fucking matter at all. If you’re not working solo, maybe you need to adopt a similar process or look at how you’re not working solo. The only time I touch another dev’s branch is at the PR stage and only for quick corrections or missing knowledge so it doesn’t matter if they rebased before or honestly rebase after before the final merge.

    • dejected_warp_core@lemmy.world
      2·
      2 years ago

      This is really the only sane way to do it. I have run into some wonkyness with the commit history of the target branch commits not resembling git log, but that’s usually for commits outside of what I’m trying to merge.

      Edit: squashing commits down this way also helps reduce problems with replaying commit history on the actual rebase. In most cases you don’t need all your “microcommits” in the history, and fewer commits just takes less time to reconcile.

  • Croquette@sh.itjust.works
    12·
    2 years 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.

    • oortjunk@sh.itjust.works
      191·
      2 years 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
        4·
        2 years 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.

        • oortjunk@sh.itjust.works
          4·
          2 years ago

          100% they do. Rebase is an everyday thing, merge is for PRs (for me anyway). Or merges are for regular branches if you roll that way. The only wrong answer is the one that causes you to lose commits and have to use reflog, cos…well, then you done messed up now son… (but even then hope lives on!)

        • JackbyDev@programming.devEnglish
          4·
          2 years ago

          Yes. They do. A lot of people will use vacuous terms like “clean history” when arguing for one over the other. In my opinion, most repositories have larger problems than rebase versus merge. Like commit messages.

          Also, remember, even if your team/repository prefers merges over rebases for getting changes into the main branch, that doesn’t mean you shouldn’t be using rebase locally for various things.

            • JackbyDev@programming.devEnglish
              2·
              2 years ago

              I must have read that blog post in the past because that’s exactly the style I use. Much of it is standard though.

              One MAJOR pet peeve of mine (and I admit it is just an opinion either way) is when people use lower case letters for the first line of the commit message. They typically argue that it is a sentence fragment so shouldn’t be capitalized. My counter is that the start of sentences, even fragmented ones, should be capitalized. Also, and more relevant, is that I view the first line of the commit more like the title of something than a sentence. So I use the Wikipedia style of capitalizing.

              • oortjunk@sh.itjust.works
                1·
                2 years ago

                https://gitmoji.dev/

                Quasi parallel reply to your other post, this would kind of echo the want for a capital letter at the start of the commit message. Icon indicates overall topic nature of commits.

                Lets say I am adding a database migration and my commit is the migration file and the schema. My commit message might be:

                     🗃️ Add notes to Users table

                So anyone looking at the eventual pr will see the icon and know that this bunch of work will affect db without all that tedious “reading the code” part of the review, or for team members who didn’t participate in reviews.

                I was initially hesitant to adopt it but I have very reasonable, younger team mates for whom emojis are part of the standard vocabulary. I gradually came to appreciate and value the ability to convey more context in my commits this way. I’m still guilty of the occasionally overusing:

                   ♻️ Fix the thing

                type messages when I’m lazy; doesn’t fix that bad habit, but I’m generally much happier reading mine or someone else’s PR commit summary with this extra bit of context added.

                • Deebster@programming.dev
                  1·
                  2 years ago

                  I looked at it and there’s a lot of them!

                  I see things like adding dependencies but I would add the dependency along with the code that’s using it so I have that context. Is the Gitmoji way to break your commits up so that it matches a single category?

          • Croquette@sh.itjust.works
            2·
            2 years ago

            How would rebasing my own branch work? Do I rebase the main into my branch, or make a copy of the main branch and then rebase? I have trouble grasping how that would work.

            • JackbyDev@programming.devEnglish
              3·
              2 years ago

              You’re still rebasing your branch onto main (or whatever you originally branched it off of), but you aren’t then doing a fast forward merge of main to your branch.

              The terminology gets weird. When people say “merge versus rebase” they really mean it in the context of brining changes into main. You (or the remote repository) cannot do this without a merge. People usually mean “merge commit versus rebase with fast forward merge”

              • Croquette@sh.itjust.works
                1·
                2 years ago

                Yeah I was confused because you are right, merge is usually refered as the git merge and then git commit.

                It makes sense. Thanks for the clarification

            • oortjunk@sh.itjust.works
              2·
              2 years ago

              Here’s an example

              Say I work on authentication under feature/auth Monday and get some done. Tuesday an urgent feature request for some logging work comes in and I complete it on feature/logging and merge clean to main. To make sure all my code from Monday will work, I will then switch to feature/auth and then git pull --rebase origin main. Now my auth commits start after the merge commit from the logging pr.

        • bitcrafter@programming.dev
          3·
          2 years ago

          Yes. My rule of thumb is that generally rebasing is the better approach, in part because if your commit history is relatively clean then it is easier to merge in changes one commit at a time than all at once. However, sometimes so much has changed that replaying your commits puts you in the position of having to solve so many problems that it is more trouble than it is worth, in which case you should feel no qualms about aborting the rebase (git rebase --abort) and using a merge instead.

          • Croquette@sh.itjust.works
            1·
            2 years ago

            I have the bad habit of leaving checkpoints everywhere because of merge squash that I am trying to fix. I think that forcing myself to rebase would help get rid of that habit. And the good thing is that I am the sole FW dev at work, so I can do whatever I want with the repos.

        • aubeynarf@lemmynsfw.com
          1·
          2 years 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
      153·
      2 years 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.

      • reflectedodds@lemmy.world
        12·
        2 years ago

        I feel the opposite, but for similar logic? Merge is the one that is cluttered up with other merges.

        With rebase you get A->B->C for the main branch, and D->E->F for the patch branch, and when submitting to main you get a nice A->B->C->D->E->F and you can find your faulty commit in the D->E->F section.

        For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits. And worse, in a git lot there is no clear “D E F” so you don’t actually know if A, D or B came from the feature branch, you just know a branch was merged at commit B’. You’d have to try to demangle it by looking at authors and dates.

        The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault. I always rebase because it’s equivalent to checking out the latest changes and re-branching so I’m never behind and the patch is always a unique set of commits.

        • Atemu@lemmy.ml
          3·
          2 years ago

          For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.

          Your notation does not make sense. You’re representing a multi-dimensional thing in one dimension. Of course it’s a mess if you do that.

          Your example is also missing a crucial fact required when reasoning about merges: The merge base.
          Typically a branch is “branched off” from some commit M. D’s and A’s parent would be M (though there could be any amount of commits between A and M). Since A is “on the main branch”, you can conclude that D is part of a “patch branch”. It’s quite clear if you don’t omit this fact.

          I also don’t understand why your example would have multiple merges.

          Here’s my example of a main branch with a patch branch; in 2D because merges can’t properly be represented in one dimension:

          M - A - B - C - C'
  \           /
    D - E - F

          The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.

          If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They’re much faster too.

          • reflectedodds@lemmy.world
            2·
            2 years ago

            You’re right, I’m not representing the merge correctly. I was thinking of having multiple merges because for a long running patch branch you might merge main into the patch branch several times before merging the patch branch into main.

            I’m so used to rebasing I forgot there’s tools that correctly show all the branching and merges and things.

            Idk, I just like rebase’s behavior over merge.

            • Atemu@lemmy.ml
              4·
              2 years ago

              The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they’re done.

      • JackbyDev@programming.devEnglish
        1·
        2 years ago

        Folks should make sure the final series of commits in pull requests have atomic changes and that each individual commit works and builds successfully alone. Things like fixup commits with auto squash rebase. THIS WAY you can still narrow it down to one commit regardless of the approach.

  • jollyrogue@lemmy.ml
    104·
    2 years ago

    git rebase is only for terrorists. 🥸

    Also for me when I’ve been drinking and committed some really stupid shit into the repo. No one needs to know what I really think of my team members.

    • 7heo@lemmy.ml
      4·
      2 years ago

      Yeah totally merge everything, people like a good spaghetti salad.

  • JoYo@lemmy.ml
    71·
    2 years ago

    Anyone mind explaining to me how git rebase is worth the effort?

    git merge has it’s own issues but I just don’t see any benefit to rebase over it.

    • Aux@lemmy.worldBanned
      61·
      2 years ago

      Well, rebase allows you to resolve the same conflict ten times in a row instead of doing it once. How cool is that?

    • Muad'Dibber@lemmygrad.ml
      4·
      2 years ago

      Only before you collaborate with anyone else. After that, don’t ever use rebase, or they’ll get an error, and will have to overwrite their local history with the one you’ve rewritten.

    • bitcrafter@programming.dev
      2·
      2 years ago

      The way I structure my commits, it is usually (but not always) easier and more reliable for me to replay my commits one at a time on top of the main branch and see how each relatively small change needs to be adapted in isolation–running the full test suite at each step to verify that my changes were correct–than to be presented with a slew of changes all at once that result from marrying all of my changes with all of the changes made to the main branch at once. So I generally start by attempting a rebase and fall back to a merge if that ends up creating more problems than it solves.