I have auto-formatting and linting configured in my text editor. It’s great for automatically fixing most code format issues and I highly recommend it. However, when working with legacy codebases, this can make for some messy diffs.

I’ll usually try to disable auto-formatting if I anticipate an issue, but sometimes I’m not expecting it or forget. Rather than manually reverting the changes, it’s usually easier to stage the changes I want, commit, and then reset the unstaged changes.

To interactively choose which parts I want to stage, I use git add -p.

From the manpage:

-p
--patch
Interactively choose hunks of patch between the index and the work tree and add them to the index. This gives the user a chance to review the difference before adding modified contents to the index.

This effectively runs add --interactive, but bypasses the initial command menu and directly jumps to the patch subcommand. See “Interactive mode” for details.

When you run the command, you’ll initially see the first part of the patch with a prompt for how you want to handle it.

(1/55) Stage this hunk [y,n,q,a,d,j,J,g,/,s,e,?]?

From the Interactive Mode docs:

y - stage this hunk
n - do not stage this hunk
q - quit; do not stage this hunk or any of the remaining ones
a - stage this hunk and all later hunks in the file
d - do not stage this hunk or any of the later hunks in the file
g - select a hunk to go to
/ - search for a hunk matching the given regex
j - leave this hunk undecided, see next undecided hunk
J - leave this hunk undecided, see next hunk
k - leave this hunk undecided, see previous undecided hunk
K - leave this hunk undecided, see previous hunk
s - split the current hunk into smaller hunks
e - manually edit the current hunk
? - print help

After staging all the relevant hunks, you can commit and push as normal. Then git reset --hard resets the other pending changes.

The GitHub Desktop app as similar functionality to commit parts of a given change using a GUI interface.