What is the best way to handle .htaccess with a git repo?

Question

Another developer says we should put .htaccess files in the git repo, but because the live server uses passwords and our local boxes don't, I said we should put them in the .gitignore. However, he says that if you have to have different .htaccess files across instances, you're doing it wrong. I argue not all server instances are going to be the same, and sometimes (if not often) they require their own configurations. He agreed that we could simply create a "htaccess" file in repo that is copied to .htaccess on live, but still preferred doing it his way. To me, things like server config should be kept out of repo. Also I'm not sure I need to change my development OS just to match a live server exactly or run VM software. Am I missing something here? Which is the best way, or what's a better alternative?

Answer 1

I think of git as mainly a tracker for software components (such as lines of code) and not software configuration.

A server password is configuration and therefore to be excluded from change control. The .htaccess file is a configuration artefact necessary (As I understand it in your case) for the correct operation of your application, and therefore subject to change control via git.

The way I see it you have two options. It strikes me as more elegant to move the configuration out of the repo, but if you have to keep it in the .htaccess file you can use smudge/clean scripts in .gitattributes. Smudge/clean filters inject defined changes into tracked content upon checkout (i.e. injecting passwords) and clean the password out of the tracked content again upon staging (i.e. substitute the password with a generic foobar).

Bear in mind, since these smudge/clean filters are defined in the git config they do not get passed around the way otherwise tracked files do, so you need to keep track yourself that the right filters are in place where they should be.

In either case, whether you keep the configuration out of the repo or do manual smudge/filter management across instances of the repo, you'd benefit from having a use protocol for git which would (amongst other things) state how you handle configuration and state rules for which smudge/clean scripts go where and/or where server configuration lives.