I set this up for my team using Uncrustify and a Git pre-commit hook. It will reject any commit which has files that don't adhere to our Uncrustify config file. If it rejects the commit it gives you a command to execute that will automatically fix your style issues.
A thought about this: Years ago I would have agreed, but now I'd strongly disagree, because of the noise it can add to diffs. When you're triaging a bug, or trying to figure out what effect someone's change had, you frequently go back through old commits, and look at the log message to see what the change was supposed to do. Perhaps a bug or side effect was introduced.
If the diff is full of additional formatting/stylistic changes, it can make it a lot harder to cut through the noise and get down to the heart of the change.
I'm not saying you should never clean up old code/files, however when I see that needs to be done, I try to do it in a separate commit that I make after the "real" change. The log message for that change is something like "Formatting", or "Cleanup, no functional changes".
Early on in the project we ran Uncrustify across our entire-codebase before introducing the pre-commit hook. The major downside to this was that git-blame now pointed to this large commit for almost every line of our project. It became a pain to trace back changes before the mass style change. Luckily we did this fairly early in the project so that it hasn't really been a big problem.
However, because the entire code-base was cleaned up at once we now have no additional noise from Uncrustify being run on our commits. The only changes to style it will ever suggest are with your current changes you are attempting to commit since everything in the repo right now is "clean".
