> The most common critique of the rebase workflow can be boiled down to inadequate support from native Git and GitHub. Rebase commands can be intimidating to ex

> The most common critique of the rebase workflow can be boiled down to inadequate support from native Git and GitHub. Rebase commands can be intimidating to execute, and recovering previous commit versions often requires unnerving dives into the Git ref-log. Since branches are effectively free, one "trick" is to backup your branch as a new branch (e.g. "git branch -f my-feature-branch-bk") before starting any voodoo^Wrebasing. There's also the tried and true fallback: https://xkcd.com/1597/ https://xkcd.com/1597/ > Even with everything done right, a rebase-centric workflow will flood your GitHub PR timeline with force push events. These force pushes happen even when you've merely rebased your changes onto a newer trunk, leaving the diff unchanged. Yes that's the price you pay for a linear history. For a high churn PR there's no need to rebase on every push, if the PR itself is still in flux and/or you're pushing purely to leverage the centralized CI system, it's fine to tack on additional "wip" commits without rebasing. It's only the final product that must be rebased to get that silky smooth linear commit history. And you should be doing that anyway so that the logical changes in your PR are unified into a single cohesive unit.