6 ms·

In practice, rebasing increases conflicts, requires teams to time their merges, and obfuscates the history of the project. I never understood why people think

In practice, rebasing increases conflicts, requires teams to time their merges, and obfuscates the history of the project. I never understood why people think this is a good pattern.

Espressosaurus 5y ago
In a large repo with many people merging, it helps keep things organized. In my experience you can make an argument for a merge-based workflow up to around 6 people. By 12 it's painful and hard to track what's going on, doubly so when you have a dev branch and multiple sustaining branches or something more complicated. By the time you get to 100 people or more committing to the same repo, it just becomes absolute chaos, and at least you can maintain a semblance of sanity in your official branches by forcing a rebase-based workflow on them.
- wruza 5y ago
  I feel like it’s one of these moments when people speak of git and everyone has their own version of the manual. git-rebase: git rebase master; Now, the snapshot pointed to by C4' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. What does it even mean to have a rebase-based workflow? In svn-like terms, does it mean that you have to sync-merge before reintegrate-merging? If yes, why is rebase stated as if something completely non-existent before and reinvented? You do sync-merge before reintegrating in svn, otherwise you’ll apply ancient-based patches to the young trunk, which is obviously not what you want. And if you do not use rebase, but use a merge-based workflow, does it mean that you apply ancient-based patches to the master? If yes, of course it will be a conflict hell, cause master could undergo few refactorings in the meantime. It is so confusing when people talk in a different slang, and you can’t tell if they invented something new or just missed something so damn obvious in the old tech. Can you please comment on which of these thoughts are [in]correct?
  - Espressosaurus 5y ago
    It's not exactly congruent to what you're describing with SVN. It's all about the DAG of commits and how we're using it to describe the history of the codebase. The end code is identical between the two workflows. A merge-based workflow maintains the work-in-progress history of commits running parallel to main before merging the two together. So your commit tree splits and reforms, with the number of branches at any one time equal to the number of people working on distinct features at one time. It shows you how a feature evolved, which there is some benefit of, but at the cost of an explosion in branches that are now part of the permanent record of your codebase and the main branch you're working in. It rapidly turns into spaghetti with even just a few people working in the repo. A rebase-based workflow will typically compress all the work in progress to a single commit, which then gets applied to the tip of the main branch. This maintains a linear flow of commits where each commit is a single PR. Maintaining that linear flow of commits is increasingly important as the number of people committing to the repo rises and the branches rise with them. Visually, a merge-based workflow might look like this: 4 |\ | \ /3 \ | 2\ | \| |/ |// |/ 1 This would represent 3 features worked on by different people, all branched off the same source (1), and then merging back in. The same thing in a rebase-based workflow would look like this: 4 | 3 | 2 | 1 All of the work in progress is collapsed into a single commit when completing the PR to maintain the linear history. Of course while it was in progress, it resembled the merge-based workflow above. The difference is that instead of merging at the end, they rebased and squashed the commits. Again, the end result in terms of the code is the same. The difference is what you see when you're navigating the history of the repo.
    - wruza 5y ago
      Thanks for taking time on such detailed explanation! So, the benefit of rebase is in a graph view of the repo, not in a conflict resolving workflow (which is consistent with the manual). But why merge-based ... rapidly turns into spaghetti with even just a few people working in the repo Isn’t it just a detail of how graph/report tools work? Can’t they track these merge points and “rebase in their ram”? I don’t get how a graphical representation of merge points may change the workflow. One more thing that is unclear is why some people think that rebase is somehow superior in terms if conflict and reintegration. Like they “had issues with svn and now that rebase is a thing, issues gone”. Maybe they didn’t understand that you have to sync-merge your branches (effectively rebasing) periodically to not diverge from trunk (or parent branch) too much? Added: I know rebase is not congruent with what I’m asking, but my questions are more about how git folks think, not about how git works. Cause I often see its comparison to other VCSs and claims that are vaguely or simply untrue about git competitors. As if before git there was some stoneage.
TheLocehiliosan 5y ago
What you need to understand is people use rebase on their unshared branches. It's part of crafting your commit history to be a coherent set of atomic changes instead of the path you took while developing it all. You rebase BEFORE you merge into the mainline branch.
- fshbbdssbbgdd 5y ago
  Do you run your test suite against each of the commits you create when rebasing? If not, isn’t this “coherent set of atomic changes” misleading? It seems like a lot of effort to make a fake clean-looking history.
  - xoudini 5y ago
    There shouldn't be an issue in doing so. During a rebase you'll either have no conflicts — in which case there isn't an issue — or you'll have to stop to resolve conflicts, and you might as well run tests before continuing the rebase. In both cases I'd argue that the statement "coherent set of atomic changes" applies.
    - fshbbdssbbgdd 5y ago
      Correct me if I’m missing something here - but a lack of conflicts during rebase only means that the few lines surrounding your changes weren’t changed in the upstream. The rest of the repo changed, and this will often cause some kind of inconsistent state. I’ve encountered this situation frequently when using git bisect.
      - xoudini 5y ago
        When you rebase, you basically replay the history of your branch since it diverged from the branch you're rebasing onto. Thus, the branch is always in a consistent state (or equally consistent to when you originally authored the commit you're replaying). And of course this assumes the target branch is already in a consistent state.
mekkkkkk 5y ago
This. I don't know if it's because of a lack of understanding or bad workflow, but almost all of the times I've seen bugs caused by git operations to slip through the cracks, it's been because someone decided that a pretty history was of upmost priority. Rebasing is probably necessary in some cases, but it can be a real foot gun as well.

In practice, rebasing increases conflicts, requires teams to time their merges, and obfuscates the history of the project. I never understood why people think this is a good pattern.

Espressosaurus 5y ago

In a large repo with many people merging, it helps keep things organized. In my experience you can make an argument for a merge-based workflow up to around 6 people. By 12 it's painful and hard to track what's going on, doubly so when you have a dev branch and multiple sustaining branches or something more complicated. By the time you get to 100 people or more committing to the same repo, it just becomes absolute chaos, and at least you can maintain a semblance of sanity in your official branches by forcing a rebase-based workflow on them.

wruza 5y ago
I feel like it’s one of these moments when people speak of git and everyone has their own version of the manual. git-rebase: git rebase master; Now, the snapshot pointed to by C4' is exactly the same as the one that was pointed to by C5 in the merge example. There is no difference in the end product of the integration, but rebasing makes for a cleaner history. What does it even mean to have a rebase-based workflow? In svn-like terms, does it mean that you have to sync-merge before reintegrate-merging? If yes, why is rebase stated as if something completely non-existent before and reinvented? You do sync-merge before reintegrating in svn, otherwise you’ll apply ancient-based patches to the young trunk, which is obviously not what you want. And if you do not use rebase, but use a merge-based workflow, does it mean that you apply ancient-based patches to the master? If yes, of course it will be a conflict hell, cause master could undergo few refactorings in the meantime. It is so confusing when people talk in a different slang, and you can’t tell if they invented something new or just missed something so damn obvious in the old tech. Can you please comment on which of these thoughts are [in]correct?
- Espressosaurus 5y ago
  It's not exactly congruent to what you're describing with SVN. It's all about the DAG of commits and how we're using it to describe the history of the codebase. The end code is identical between the two workflows. A merge-based workflow maintains the work-in-progress history of commits running parallel to main before merging the two together. So your commit tree splits and reforms, with the number of branches at any one time equal to the number of people working on distinct features at one time. It shows you how a feature evolved, which there is some benefit of, but at the cost of an explosion in branches that are now part of the permanent record of your codebase and the main branch you're working in. It rapidly turns into spaghetti with even just a few people working in the repo. A rebase-based workflow will typically compress all the work in progress to a single commit, which then gets applied to the tip of the main branch. This maintains a linear flow of commits where each commit is a single PR. Maintaining that linear flow of commits is increasingly important as the number of people committing to the repo rises and the branches rise with them. Visually, a merge-based workflow might look like this: 4 |\ | \ /3 \ | 2\ | \| |/ |// |/ 1 This would represent 3 features worked on by different people, all branched off the same source (1), and then merging back in. The same thing in a rebase-based workflow would look like this: 4 | 3 | 2 | 1 All of the work in progress is collapsed into a single commit when completing the PR to maintain the linear history. Of course while it was in progress, it resembled the merge-based workflow above. The difference is that instead of merging at the end, they rebased and squashed the commits. Again, the end result in terms of the code is the same. The difference is what you see when you're navigating the history of the repo.
  - wruza 5y ago
    Thanks for taking time on such detailed explanation! So, the benefit of rebase is in a graph view of the repo, not in a conflict resolving workflow (which is consistent with the manual). But why merge-based ... rapidly turns into spaghetti with even just a few people working in the repo Isn’t it just a detail of how graph/report tools work? Can’t they track these merge points and “rebase in their ram”? I don’t get how a graphical representation of merge points may change the workflow. One more thing that is unclear is why some people think that rebase is somehow superior in terms if conflict and reintegration. Like they “had issues with svn and now that rebase is a thing, issues gone”. Maybe they didn’t understand that you have to sync-merge your branches (effectively rebasing) periodically to not diverge from trunk (or parent branch) too much? Added: I know rebase is not congruent with what I’m asking, but my questions are more about how git folks think, not about how git works. Cause I often see its comparison to other VCSs and claims that are vaguely or simply untrue about git competitors. As if before git there was some stoneage.

TheLocehiliosan 5y ago

What you need to understand is people use rebase on their unshared branches. It's part of crafting your commit history to be a coherent set of atomic changes instead of the path you took while developing it all. You rebase BEFORE you merge into the mainline branch.

fshbbdssbbgdd 5y ago
Do you run your test suite against each of the commits you create when rebasing? If not, isn’t this “coherent set of atomic changes” misleading? It seems like a lot of effort to make a fake clean-looking history.
- xoudini 5y ago
  There shouldn't be an issue in doing so. During a rebase you'll either have no conflicts — in which case there isn't an issue — or you'll have to stop to resolve conflicts, and you might as well run tests before continuing the rebase. In both cases I'd argue that the statement "coherent set of atomic changes" applies.
  - fshbbdssbbgdd 5y ago
    Correct me if I’m missing something here - but a lack of conflicts during rebase only means that the few lines surrounding your changes weren’t changed in the upstream. The rest of the repo changed, and this will often cause some kind of inconsistent state. I’ve encountered this situation frequently when using git bisect.
    - xoudini 5y ago
      When you rebase, you basically replay the history of your branch since it diverged from the branch you're rebasing onto. Thus, the branch is always in a consistent state (or equally consistent to when you originally authored the commit you're replaying). And of course this assumes the target branch is already in a consistent state.

mekkkkkk 5y ago

This. I don't know if it's because of a lack of understanding or bad workflow, but almost all of the times I've seen bugs caused by git operations to slip through the cracks, it's been because someone decided that a pretty history was of upmost priority. Rebasing is probably necessary in some cases, but it can be a real foot gun as well.