Not necessarily, I don't think anyone works linearly, but you can still keep your commits organized. I might have 25 dirty files and a bunch of WIP commits; whe

Not necessarily, I don't think anyone works linearly, but you can still keep your commits organized. I might have 25 dirty files and a bunch of WIP commits; when I'm done I will reset everything, and take the time to stage them one by one (or `git add -p`) into commits that make sense, and will help a reviewer understand what's happening. It's worth the extra few minutes. For a more concrete example, say you're adding a new screen to a mobile app, I'll probably split into chunks like these: - add new `/foo` endpoints to API - add `NewScreen` (can be reviewed as a feature, does the screen contain / do what it's suppose to) - add `NewScreen` to navigation stack - link to `NewScreen` from settings page - add tracking for `NewScreen` Each of these have very different purposes, and I find being able to focus on the different aspects (business logic, infrastructure stuff, analytics) helps a lot. They can also be reverted cleanly if needed without destroying all of the work. You can still review the entire PR at once, with the option to drill down into individual commits if desired.