There are a couple of different ways to deal with this problem. It all depends on your personal preference.
Don't commit any configuration files
This is probably the easiest, although you have to make sure you never accidentally commit anything with configuration information in it. With git, once it has been committed and pushed out or forked it's practically impossible to remove it. If you ever leaked anything in a configuration file that was pushed, consider that information compromised.
Major disadvantage here is that you have to maintain some kind of documentation on the structure and entries you need in the configuration file. Deploying the application means creating a configuration file for your environment. A new version that adds a configuration option will need some kind of documentation on the deployment process for the new version to make sure this option is set.
Commit a sandbox-file
A lot of projects favor an approach where you can check out, build and run an application without the need to do any configuration. You can achieve this by providing a default configuration file. For your database, this file could just point to a localhost database-server with 'myproject_user' as username and 'myproject_password' as password for the 'myproject_db'. This has the advantage of providing a default configuration file with all options present AND is part of the code because it runs with the application, unlike your documentation.
Downside is that in this case people checking out your application have to set up their environment to match this, or still change the configuration settings. Does not fix the issue with having to remember to set configuration values on deployment either.
Provide a parameters.dist-file that is checked at deploy-time
Frameworks such as Symfony actually version configuration files by having a parameters.yml.dist-file. (see http://symfony.com/doc/current/best_practices/configuration.html). This is a template file that simply contains the structure of the config file, without any values, and during deployment compares the existing parameters.yml-file to the parameters.yml.dist-file that is deployed. Obsolete entries are dropped and new entries that need a value prompt to the person deploying the app for a value.
This is a solid approach for big applications and frameworks that will be used in other applications or by external parties, but might be overkill for smaller applications where deployment is often a simple copy/past or FTP upload and you can follow a deployment-document that outlines what entries you need to change.