My company previously had a beautiful (but unconventional and much-misunderstood) solution to this issue. To merge a feature branch into master, we would _first

My company previously had a beautiful (but unconventional and much-misunderstood) solution to this issue. To merge a feature branch into master, we would _first_ create a squash commit consisting of all the changes with the commit text containing the review message and a link to code review. Immediately after, we would _also_ add a merge commit that referenced the original feature branch, but resulted in no changes to master. This meant that log/blame would default to showing the high-level summary of each review, but the git commit graph still has the full gory history if anyone needs to look at it. More importantly, you could safely start developing on top of someone else's unreviewed changes and git would correctly be able to track who made what changes, in a way that breaks badly with a standard squash or rebase workflow. To view the "simplified" linear history, you run "git log --first-parent --no-merges", which unfortunately doesn't have a config option to set as default. Unfortunately, we lost this workflow when we moved over to GitHub, and now git blame is surfacing everyone's broken wip commits because we've stopped adding the high-level summary squash commits.