3 ms·
I love rebasing, and use it most of the time. At work we also enforce squash-merging, which is the only scalable way to prevent low quality commits from polluti
by ak217 2y ago
I love rebasing, and use it most of the time. At work we also enforce squash-merging, which is the only scalable way to prevent low quality commits from polluting the main branch history.
While rebasing works most of the time, the problem arises when actually collaborating on feature branches - especially when your collaborator is not confident enough with git to realize when a rebase conflict might lose data. Merging works better in these situations. So while standardizing on rebasing is great for productivity across the org, you also have to watch out for this and make sure developers don't lose the ability to collaborate on branches.
- The_Colonel 2y agoWhat's the point of rebasing when you in the end squash-merge? In my mind the only real benefit of rebasing is that you split your work into a couple of "nice" commits, but if you squash them anyway... Ok, I've seen people doing this to ease the review process and I guess it makes sense sometimes, but to me it's still a largely "not worth it" effort.
- sensanaty 2y agoThe squash merge is for the sanity of master/main, whereas rebase is for the sanity of the reviewer. That's how I look at it at least
- account42 2y agoIf your developers can't manage to create sensible commits then do you really want them to make code changes? Workflows with linear history made up of logical commits "scale" just fine, you just need to train your developers accordingly.