How to live the principle of atomic commits?

Question

I understand that it is a good idea to do atomic commits of your code changes in the version control system. However, what I am not good in, is to really live that.

Just for clarification: I am talking about commits on a development branch. For me "atomic commit" means not to do one commit per dev ticket, but doing a commit whenever one relevant change has been done and the code could be compiled again.

Unfortunately when I do some code changes, I regularly run into the situation, that I find other changes have to be done first.

One (simple) example would be: I add a configuration switch to activate a new feature. While implementing the evaluation of that switch, I find out that the evaluation code would duplicate some already existing code. So I extract that code into a new method and replace all already existing duplicates by a call to that method. What I now would like to do, is to do one commit "new utility method for checking xy" with the new method and all the calls to that method, but without the changes for the configuation switch as this is not ready yet and in my understanding not related to that atomic commit.

When all these changes are in different classes, it is easy to commit only the classes that are related to one commit, but when the changes are in one class, the only way that I know to commit that is using TortoiseGit's "Restore after commit" feature, what is not really comfortable. Do you know better ways how to handle that? The best thing would be to have the feature integrated into the IDE, so that changes could be immediately "tagged" with the correct commit message.