title: Best practice for a git repo for system config files (nginx/php.ini etc)
body: <p>I have a fairly (I think) normal setup, on a CentOS 6 box.</p>
  
  <p>My websites are in /var/www/sites.</p>
  
  <ul>
  <li>/var/www/sites/site1</li>
  <li>/var/www/sites/site2</li>
  <li>etc...</li>
  </ul>
  
  <p>I have a git repo for each one inside each of those folders.</p>
  
  <p>I'd like to create a git repo for various config files:</p>
  
  <ul>
  <li>/etc/nginx.conf</li>
  <li>/etc/nginx/sites-available/</li>
  <li>/etc/php.ini</li>
  <li>/etc/my.cnf</li>
  <li>etc...</li>
  </ul>
  
  <p>I feel I could create a git repo in the /etc/ folder, have a .gitignore with a * wildcard to ignore all, and then force-add the specific files I'm interested in. Is that bad practice?  Feels a bit "dirty" somehow.</p>
  
  <p>What if I decide there's an important file outside of /etc/ that I'd like though, maybe some config has ended up in /opt/ instead.  So maybe I should create a repo on /.  Hmm, starting to feel even dirtier, especially since this repo would then "contain" my website repos... even if they are excluded via the wildcard .gitignore - it just seems a bit... wrong.  Is it?</p>
  
  <p>I guess an alternative would be to create a /config/ directory with a repo in it, move all of the relevant files to it and then add symlinks for where the files are expected to be.  No idea if that could cause unwanted complications/issues?</p>
  
  <p>Presumably I'm not the first person to want a "config repo" - what do most people end up doing?</p>
  
  <p>Thanks</p>