The git history on my personal/dev-machine are an absolute mess that I try to optimize for `git bisect`, so preferably each commit should compile (and I usually

The git history on my personal/dev-machine are an absolute mess that I try to optimize for `git bisect`, so preferably each commit should compile (and I usually commit whenever a new part of the requirements is introduced/a new test passes) The way our code review system works is essentially each upload is a commit, so the review's history is like a compressed version of the local git history. I usually upload when I think the branch is "complete"/will pass all of the CI, and ~once per round of comments. The main git history is squash-and-rebase, so one commit per code-review, with the CR description serving as the commit message (with automatic links to bugs and code reviews and the like). I personally like the squash-and-merge strategy for the main branch, it makes the most sense (especially when the code review's history is still around after)