3 ms·
> The problematic use of rebase is on pushed branches. Especially if you have collaborators. Yep. As soon as you have a PR out, and have to address comments, y
by SAI_Peregrinus 3y ago
> The problematic use of rebase is on pushed branches. Especially if you have collaborators.
Yep. As soon as you have a PR out, and have to address comments, you have a public branch and can't safely rebase it. So you can't roll those new changes in to the "clean" history, If upstream also has changes before your PR gets merged, you'll also have to add a merge commit anyway.
- morelisp 3y agoThis is a problem of GitHub, not Git. E.g. GitLab preserves comments as well across rebases as any commit changes. "Don't rebase public branches" is an easy way to say "if someone has built something on top your branch, don't rebase unless you expect them to also rebase." 90% of the time this is not actually harder than merging, though, and still produces a better history and more atomic commits. At this point I'm even only 99% firm on "never rebase master", as long as release tags are truly immutable.