4 ms·
Personally, I actually stopped using rebase or advocating it's use (because noobies mess up their history all the time with it). I just commit whatever, then w
by rubyist5eva 4y ago
Personally, I actually stopped using rebase or advocating it's use (because noobies mess up their history all the time with it). I just commit whatever, then when the code is merged to trunk/dev/master/whatever I use `merge --squash`.
Reviews are very rarely happening on the commit level, so having lots of small "meaningless" commits (lint fixes, fix spec, add thing) hasn't been an issue but having squashed merge commits (effectively a rebase that squashes everything) has made release management so much easier for our team.
It also has the benefit of just less cognitive overhead of micro-managing my feature branch commits that are WIP or currently in-review.
- jokab 4y agoThanks. I thought it was just me.
- dabears 4y agoThis is my workflow as well, it's great. Github is configured so merging a PR into master will automatically produce a squashed commit. My rule of thumb, always rebase unless you hit a series of merge conflict while rebasing. Then either merge, or squash your branch then re-run the rebase.
- rubyist5eva 4y agoWe require linear history on our shared mainline branches so the squash workflow works great for us using Github as well. Another benefit is the "show changes since last review" option when reviewing a PR - it's been a while but I'm not sure if this is possible with a rebase-based workflow.