git rebase: what can go wrong?

git rebase: what can go wrong?

Julia Evans
@b0rk you asked about real-life users of the GitHub squash-and-merge strategy: that’s my team. Folks who are confident with rebase can use it to keep their PRs tidy, folks who prefer not to can merge main into their branches, and either way we squash to land the PR. We like squashing also because we find individual commits relevant for code review but whole-PR granularity more useful for long-term history (e.g. it’s easier to match to our ticketing system).
@tikitu @b0rk I'm a rebase person myself, but my team uses squash + merge for the sole purpose of making sure ci ran on every merged patch. Doing multi-commit rebase merges (in github parlance) means ci steps only run for the last commit in the series, so the preceding commits might be broken, and nobody would notice until they tried git-bisect.