Tastefully broken commits turn a big change into a clear story. Instead of one giant commit that mixes manual tweaks and automated fixes, you split it into steps that may even fail tests or not compile. First you make the manual edit—say adding a new formatter—then you run it across 3,000 files in a second commit, and finally you fix any leftovers. That way a reviewer can check each piece: rerun the formatter on the parent commit, verify the config tweak, then move on. Mixing those steps hides the intent and buries tiny but important manual edits beneath a wall of machine output. You keep your long-term history clean with “squash and merge.” Locally you write multiple commits—units of review—that guide your teammate through each mechanical shift or file rename. When it’s time to land, those get squashed into a single atomic commit—your unit of persistence. Anyone digging through git log or git blame still finds the pull request and its internal discussion, so nothing useful vanishes even though the main branch shows one neat change. Broken commits shine whenever mechanical and “real” changes collide. Update or add a lint rule? Change the config first, auto-fix next, then tweak the leftovers. Rename a function or file? Commit the rename alone so it doesn’t look like a delete-and-recreate. Big re-indents, code moves or AI-generated patches all benefit. You plan ahead, commit often, and then rebase interactively to forge a logical sequence. And when AI spits out some “all-in-one” patch, you prompt it to pause, commit, and narrate its steps so you don’t miss a stray bug hidden in that wall of code.