3 ms·

Realistically, how much does merging vs rebasing actually matter - do you save days of time over the year, or just a few minutes cumulatively because the commit

Realistically, how much does merging vs rebasing actually matter - do you save days of time over the year, or just a few minutes cumulatively because the commit graph is prettier? I understand that it makes the history "cleaner," but how frequently do you end up bisecting manually searching the repo's commit history? Even on large projects with dozens of feature branches that eventually make it through a dev / main / prod branch, I've never had a problem when merge was the default rule. But maybe we never hit an otherwise common problem.

aljgz 3y ago
Staying consistent matters. Once I joined a new team and my first task was to take care of a large code reformat everyone was afraid of taking over. I had done a similar thing many times, a super easy thing once you know git and are focused. It turned out a terrible experience for a combination for reasons, but one important reason was that the team used merge workflow, I had always done this in rebase. Don't remember the exact details though.
Apes 3y ago
In practical terms, fixing merge conflicts and running git bisect are a lot more time consuming when you have a lot of merge commits.
- kevingadd 3y ago
  It's just plain harder to reason about the history of a branch when there are a bunch of merge commits in it. Even if I'm not using bisect (I rarely do), having the 'git log' be polluted by merges makes it harder for me to fit everything into my head. I also prefer to think about my branches as 'here is a stack of commits on top of a fixed point in time', so having merges in the middle of that flow makes it much harder to reason about that way. Rebasing to choose a new fixed point is much simpler.
  - feanaro 3y ago
    > Even if I'm not using bisect (I rarely do), having the 'git log' be polluted by merges makes it harder for me to fit everything into my head. How and why? Done properly, a merge commit of a PR breach is semantically equivalent to a squashed PR commit, from the perspective of the "trunk"/main/master branch. It is the commit introducing all of the changes of the PR branch into the trunk branch. If you're about to reason about squashed PR commits, you should be able to reason about merge commits. The only difference is that with merge commits you still have the individual commit granularity available, should you be interested in it.
  - rand_flip_bit 3y ago
    Both the git log and git bisect commands accept the --first-parent flag, which eliminates the complexities of dealing with merge commits in the history.
cryptonector 3y ago
> Realistically, how much does merging vs rebasing actually matter - do you save days of time over the year, or just a few minutes cumulatively because the commit graph is prettier? Excellent question! This is one of those how-to-measure-intangibles sort of question, so there's really no good answer to it. The issue is that bisection is really useful when you have a hard-to-find bug, and so the question is really "how often do you have such bugs", and the answer is hard to find because few companies require recording of such metadata in their bug reporting systems.

aljgz 3y ago

Staying consistent matters. Once I joined a new team and my first task was to take care of a large code reformat everyone was afraid of taking over. I had done a similar thing many times, a super easy thing once you know git and are focused. It turned out a terrible experience for a combination for reasons, but one important reason was that the team used merge workflow, I had always done this in rebase. Don't remember the exact details though.

Apes 3y ago

In practical terms, fixing merge conflicts and running git bisect are a lot more time consuming when you have a lot of merge commits.

kevingadd 3y ago
It's just plain harder to reason about the history of a branch when there are a bunch of merge commits in it. Even if I'm not using bisect (I rarely do), having the 'git log' be polluted by merges makes it harder for me to fit everything into my head. I also prefer to think about my branches as 'here is a stack of commits on top of a fixed point in time', so having merges in the middle of that flow makes it much harder to reason about that way. Rebasing to choose a new fixed point is much simpler.
- feanaro 3y ago
  > Even if I'm not using bisect (I rarely do), having the 'git log' be polluted by merges makes it harder for me to fit everything into my head. How and why? Done properly, a merge commit of a PR breach is semantically equivalent to a squashed PR commit, from the perspective of the "trunk"/main/master branch. It is the commit introducing all of the changes of the PR branch into the trunk branch. If you're about to reason about squashed PR commits, you should be able to reason about merge commits. The only difference is that with merge commits you still have the individual commit granularity available, should you be interested in it.
- rand_flip_bit 3y ago
  Both the git log and git bisect commands accept the --first-parent flag, which eliminates the complexities of dealing with merge commits in the history.

cryptonector 3y ago

> Realistically, how much does merging vs rebasing actually matter - do you save days of time over the year, or just a few minutes cumulatively because the commit graph is prettier? Excellent question! This is one of those how-to-measure-intangibles sort of question, so there's really no good answer to it. The issue is that bisection is really useful when you have a hard-to-find bug, and so the question is really "how often do you have such bugs", and the answer is hard to find because few companies require recording of such metadata in their bug reporting systems.