The basic idea is that you do NOT check-in confidential values in the code or in the compiled binary. Especially if the project is open source you really shouldn't. There are several configuration strategies you can take in order to do so:
Placeholders in code (hardcoded values)
Placeholders in code - as was suggested - which is most sane and easiest to do in dynamic programming languages as the code is easy to change (without needing to compile). I've seen a lot of open source projects do this such as MediaWiki with it's
The downside with this strategy is that the key is hardcoded. So if the program is distributed as a binary then having the key hard-coded does not make it particularly maintainable.
Configuration Text Files
You can also do this by implementing configuration text files, i.e. the program/application searches for a configuration file and reads values from it. You can check-in a sample configuration with placeholders but have the actual configuration local in your machine.
In your case you can create a
key.conf text file with the actual key, let the program use that file and let it be ignored by version control. You can, for being helpful, check in a
key.conf.example text file with a bogus key and check that-in. Make sure your program/application makes an helpful error message
for the user to add the actual key in the correct file.
Some programming languages have APIs that provide this automatically for you, such as:
If your application is a database app, then consider putting the key or other configuration variables in the database. It is the same as the configuration text file above but you put all configuration variables such as the key in a database table instead.
Through preferences view or a Back Office app
If the program is a window or a web application with views then you can also let the application create the configuration file, through a preferences view of sorts. That way you don't need to check in an example config file as suggested above.
MediaWiki solved this similarly by auto-generating the
LocalSettings.php file in an initial installation process.
Admittedly this is not an option for programs that solely run as background processes, services or daemons. However that's why you create seperate GUI projects for these to create a point-of-entry for administration and preferences settings, in web apps usually called a Back Office application.