Couple different things going on here, but my two cents:
1) Philosophically: if a file may be modified somehow in any of its remote deployment contexts, don’t keep it in the repo. Since W3TC keeps its settings in a flat file (and that flat file is updated every time you go into the W3TC settings screen in any context and hit “save”), it’s difficult to ensure that changes made in any context make their way back to the repo (and subsequently to your other contexts). So, any config updates made directly on prod will be blown away the next time you push code up. Know what I mean?
2) Since some of W3TC’s functionality is environment specific (as you said, memcahce vs not, apache vs nginx, etc.), it’s not instructive to test it on a local environment that is substantially different than production. You can’t create identical configs, because your environments are not identical. This is logical. I’d consider setting up a staging environment (identical to your prod setup), where you can test your W3TC settings. Once you’ve got your settings dialed in, you can use W3TC’s export/import feature to move settings between environments. And if you want, you can save that export file (rather than the auto-generated settings file) into your repo for future reference. Kind of a poor-man’s SCM, but works for things like this that don’t need to change often, and can stand some manual setup.
There are plenty more “complete” solutions if you want to get into more complex deployment scenarios. If you’re using a tool like Bamboo, you can literally script every aspect of the deploy. But with your setup, I’d just take the W3TC config out of SCM altogether, and take a manual approach. As a long-term goal, maybe look at running virtual machines locally instead of MAMP–they let you literally replicate your prod environment locally. But they come with a steep learning curve.