Q:

strategy to follow when a file is relevant to two different commits

I have a file that I am about to commit to my repo, but it is relevant to two different commits.
It is a PHP that produces the class name that some css files use. So I want to commit all of them at the same time, but if I do that, I won't have a chance to specify the bugfix I made in the PHP file that outputs the class names. 
On the other hand, if I do two separated commits so I can specify all the history properly for each commit, if in the future I checkout the commit where I made changes to the CSS, that commit won't work as the correct PHP won't be available, so I (or any other developer) will have to be go two steps back (one for the css files, another for the php bugfixed) in the branch for the whole thing to work.
What is the most adequate strategy in this scenario?

A:

To me, it sounds like you want to squash those commits together so that they are merged as one commit.  It doesn't sound like it's ideal, but with a squash you can keep the separate commit message history for each commit being squashed, but it will be in one commit.
Here is some awesome documentation on using git rebase -i which can perform squash.

