It does NOT keep history accurate. You have absolutely no guarantee that all rebased commits work as intended or can even be built. The only thing that can be rebased safely is a single commit, for the rest you should learn to live with a messy history. It doesn't really matter anyway as long as you have procedures to prevent criss-cross merges.
If you require that each individual commit meets semantic criteria then you can still require that to occur during a git rebase by rewriting the commit. Which you should probably be doing anyways, if you're pulling breaking changes from upstream.
Exactly. It makes sense to rebase for a single commit or two when you're syncing with a remote frequently, but in any other case merge is much more sane.
