3 ms·

I think you're doing it wrong. The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means

I think you're doing it wrong. The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. If you rebase once right at the end then, sure, it's no different to merging.

epolanski 2y ago
I'm not doing it wrong, I'm questioning whether it's worth the effort. I have spent hours rebasing on very active branches when a merge would've taken minutes (as many colleagues do) just because "it's a best practice" but I've never got to fully appreciate the benefits.
- wakawaka28 2y ago
  You don't have to keep rebasing your entire history on long-running branches. That will generate a ton of conflicts. But before you wrap it up it would be preferable for you to reduce your changes into one or a handful of stand-alone commits. If you're going to rebase often onto very active branches then you need to reduce the commits as much as possible to minimize the work involved. Ideally you could get other people to coordinate their work too. The main reason people want to rebase instead of merging is to keep the commit history from looking like a bowl of spaghetti. A commit history like that is hard to navigate, and more likely to contain a lot of frivolous edits.
  - hughesjj 2y ago
    Also if you use rerere you don't really spend much time doing repetitive rebases after the first rebase
  - globular-toast 2y ago
    You should do the squashing/fixing regularly too, not once right at the end. Again, rebasing gives you the chance to fix these things as soon as it happens, rather than deal with one massive merge conflict at the end of a long running feature branch.
- throwaway918299 2y ago
  merge feature branches when reintegrating main, squash merge onto the main branch when you’re finished - best of both worlds imo I never need to rebase, or unfuck a botched rebase or go reflog diving - and the commit history is linear where it matters.
  - lmm 2y ago
    Makes the history less useful for bisection - you'll always land on a squash merge rather than the specific commit that caused the problem.
    - throwaway918299 2y ago
      In practice that's never been a problem for me. Work is delivered in functional units and segmented "sections" of code are basically useless on their own for the purpose of debugging.
- globular-toast 2y ago
  So here's the thing: if you are putting more work into rebasing but not getting anything more out of it, you are doing it wrong. You should always do the easiest thing that gets you what you want, otherwise you're just doing pointless work. If you and your colleagues are happy merging and you find that easier, that's what you should be doing. Rebasing supports a totally different workflow. With a rebase I can submit a well-formed set of changes for review that are conflict free. You can't do that with merging. With merging you submit a bunch of crap "history" that nobody will ever look at and the project maintainer has to deal with the conflicts. Merge commits look like this (newest to oldest): * Final tweaks * Merge master branch * Implement bar * Fix foo * Merge master branch * Shit I did on Wednesday before lunch * Implement foo * End of day Totally impenetrable mess that nobody will ever look at. Rebased commits look like this: * Add customise option to UI * Add use case baz * Extend model to support bar * Refactor model foo These can be reviewed in insolation and when approved they merge without conflict. If you want to do this but none of your colleagues are on board and you don't have the swing to make them, then I'm sorry. But you are wasting your time rebasing in that case. :(
  - seanwilson 2y ago
    Doesn't the rebased commits example take longer to put together than the merge commits example (where you'd likely want to just squash the merge commits)? The merge version looks like the way code is actually written in practice to me, so doesn't the rebased version take extra time to create after you're done adding code? E.g. the "Add use case baz" rebase commit isn't likely to be a simple squashing of commits from the merge version, but cherrypicking specific lines from multiple commits. I fully agree the rebased version is nicer, but I'm not seeing anyone talk about how much extra time it takes. Or you're doing it in a way that doesn't take much time somehow?
    - globular-toast 2y ago
      Yeah, it takes longer, but with the right tools and practice it doesn't take much longer. The main thing is rebasing often, reordering commits, using commit --amend, fixup commits, git autofixup and rebase --autosquash. That and being determined to deliver rebased commits from the start. I'm not saying that every single feature must be split into multiple commits. If it's one change then just keep amending that one change as you go. But quite often you'll identify standalone changes as you go, like refactors, little unrelated bugfixes you find as you go etc. When this happens I'll commit that unrelated change separately and rebase to reorder it so it comes first, then continue amending my feature commit. The paradigm shift for a lot of people is not to think of git as tracking history. Nobody cares about that. It's useless to you and doubly useless for everyone else. Think instead about tracking changes. I don't need to know every key press, every dead end explored or what you did on Tuesday afternoon. I want to know what changes are being applied to the project.
lmm 2y ago
> The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. You can do that with merge just as easily though - just merge master into your branch.
- globular-toast 2y ago
  Yes but at that point you might as well squash down to one commit and rebase because now you're tracking "history" which is useless, rather than tracking changes/versions.
  - lmm 2y ago
    WTF? If you keep the original history and regularly merge master into feature branches you're tracking people's actual edits as they worked on their feature, which is the most useful thing to have when bisecting, but you're also staying close to mainline during development. It's the best of both worlds.
    - globular-toast 2y ago
      Yeah it's sure useful when I bisect and find that commit Joe Coder made at the end of the day called "End of day. Tests not passing". Bisect only makes sense when commits are rebased into changes. The moment you bring in a regression you've fucked your ability to effectively bisect.
      - lmm 2y ago
        > Yeah it's sure useful when I bisect and find that commit Joe Coder made at the end of the day called "End of day. Tests not passing". So your automated bisect tells you to look at two whole commits instead of one. Big deal. If you keep history as-is, most commits will compile and pass tests because coders tend to compile and run tests as part of their work cycle (and the occasional isolated non-compiling or non-test-passing commit isn't a problem for a bisect). If you rebase you will end up with long chains of commits that don't compile unless you have some additional mechanism to prevent that.

epolanski 2y ago

I'm not doing it wrong, I'm questioning whether it's worth the effort. I have spent hours rebasing on very active branches when a merge would've taken minutes (as many colleagues do) just because "it's a best practice" but I've never got to fully appreciate the benefits.

wakawaka28 2y ago
You don't have to keep rebasing your entire history on long-running branches. That will generate a ton of conflicts. But before you wrap it up it would be preferable for you to reduce your changes into one or a handful of stand-alone commits. If you're going to rebase often onto very active branches then you need to reduce the commits as much as possible to minimize the work involved. Ideally you could get other people to coordinate their work too. The main reason people want to rebase instead of merging is to keep the commit history from looking like a bowl of spaghetti. A commit history like that is hard to navigate, and more likely to contain a lot of frivolous edits.
- hughesjj 2y ago
  Also if you use rerere you don't really spend much time doing repetitive rebases after the first rebase
- globular-toast 2y ago
  You should do the squashing/fixing regularly too, not once right at the end. Again, rebasing gives you the chance to fix these things as soon as it happens, rather than deal with one massive merge conflict at the end of a long running feature branch.
throwaway918299 2y ago
merge feature branches when reintegrating main, squash merge onto the main branch when you’re finished - best of both worlds imo I never need to rebase, or unfuck a botched rebase or go reflog diving - and the commit history is linear where it matters.
- lmm 2y ago
  Makes the history less useful for bisection - you'll always land on a squash merge rather than the specific commit that caused the problem.
  - throwaway918299 2y ago
    In practice that's never been a problem for me. Work is delivered in functional units and segmented "sections" of code are basically useless on their own for the purpose of debugging.
globular-toast 2y ago
So here's the thing: if you are putting more work into rebasing but not getting anything more out of it, you are doing it wrong. You should always do the easiest thing that gets you what you want, otherwise you're just doing pointless work. If you and your colleagues are happy merging and you find that easier, that's what you should be doing. Rebasing supports a totally different workflow. With a rebase I can submit a well-formed set of changes for review that are conflict free. You can't do that with merging. With merging you submit a bunch of crap "history" that nobody will ever look at and the project maintainer has to deal with the conflicts. Merge commits look like this (newest to oldest): * Final tweaks * Merge master branch * Implement bar * Fix foo * Merge master branch * Shit I did on Wednesday before lunch * Implement foo * End of day Totally impenetrable mess that nobody will ever look at. Rebased commits look like this: * Add customise option to UI * Add use case baz * Extend model to support bar * Refactor model foo These can be reviewed in insolation and when approved they merge without conflict. If you want to do this but none of your colleagues are on board and you don't have the swing to make them, then I'm sorry. But you are wasting your time rebasing in that case. :(
- seanwilson 2y ago
  Doesn't the rebased commits example take longer to put together than the merge commits example (where you'd likely want to just squash the merge commits)? The merge version looks like the way code is actually written in practice to me, so doesn't the rebased version take extra time to create after you're done adding code? E.g. the "Add use case baz" rebase commit isn't likely to be a simple squashing of commits from the merge version, but cherrypicking specific lines from multiple commits. I fully agree the rebased version is nicer, but I'm not seeing anyone talk about how much extra time it takes. Or you're doing it in a way that doesn't take much time somehow?
  - globular-toast 2y ago
    Yeah, it takes longer, but with the right tools and practice it doesn't take much longer. The main thing is rebasing often, reordering commits, using commit --amend, fixup commits, git autofixup and rebase --autosquash. That and being determined to deliver rebased commits from the start. I'm not saying that every single feature must be split into multiple commits. If it's one change then just keep amending that one change as you go. But quite often you'll identify standalone changes as you go, like refactors, little unrelated bugfixes you find as you go etc. When this happens I'll commit that unrelated change separately and rebase to reorder it so it comes first, then continue amending my feature commit. The paradigm shift for a lot of people is not to think of git as tracking history. Nobody cares about that. It's useless to you and doubly useless for everyone else. Think instead about tracking changes. I don't need to know every key press, every dead end explored or what you did on Tuesday afternoon. I want to know what changes are being applied to the project.

lmm 2y ago

> The point of rebasing is to do it often, like every day at the very least for an active integration branch. This hopefully means you'll resolve any conflicts as soon as they happen, while it's still fresh in everyone's heads. You can do that with merge just as easily though - just merge master into your branch.

globular-toast 2y ago
Yes but at that point you might as well squash down to one commit and rebase because now you're tracking "history" which is useless, rather than tracking changes/versions.
- lmm 2y ago
  WTF? If you keep the original history and regularly merge master into feature branches you're tracking people's actual edits as they worked on their feature, which is the most useful thing to have when bisecting, but you're also staying close to mainline during development. It's the best of both worlds.
  - globular-toast 2y ago
    Yeah it's sure useful when I bisect and find that commit Joe Coder made at the end of the day called "End of day. Tests not passing". Bisect only makes sense when commits are rebased into changes. The moment you bring in a regression you've fucked your ability to effectively bisect.
    - lmm 2y ago
      > Yeah it's sure useful when I bisect and find that commit Joe Coder made at the end of the day called "End of day. Tests not passing". So your automated bisect tells you to look at two whole commits instead of one. Big deal. If you keep history as-is, most commits will compile and pass tests because coders tend to compile and run tests as part of their work cycle (and the occasional isolated non-compiling or non-test-passing commit isn't a problem for a bisect). If you rebase you will end up with long chains of commits that don't compile unless you have some additional mechanism to prevent that.