The newfangled approach is something like HashiCorp's Vault, which is a dream when you're looking at more than half a dozen systems with similar roles. A different approach that I like to use for single or smaller cluster systems is Ansible's Vault and rolling out config files based on templates per environment. All actual config files are gitignored so I don't have do deal with conflicts on the server if I use a git-pull style deployment, and ansible itself can backup/version whenever they change.
Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.
I'm aware of the implications concerning the history, but sorry, the machine park is two machines. Setting up vault would just be total overkill. The people that have access to that repo change like once every few years. The repo will never go public. Let's keep the solution at least somewhat tailored to the problem.
Hey, I'm not arguing one way or the other. I like using Ansible for configuration in the way I work. I can trust that I can show my best friend and my worst enemy my project and they won't have the capability of making my life hell. Rock on though. Use the simplest solution for the problem at hand. If you're just managing two boxes though, I'd have a hard time coming up with an argument for adding more complexity to the setup to essentially make it unchanged.
It's all chef-based so we could be using encrypted databags, but as anybody with access to the repo has root on the machines anyways, there's little to gain there as well, especially given the very limited security implications. I'd be more worried that somebody adds his account to the sudoers list that stealing the secret data. But hey, things were that way when I joined and there's better places to spend my time to improve security.
Additionally, git does keep that history (as it's supposed to), so if you just delete the key from a private repo as you're trying to make the repo public, it's trivial for someone to walk the commit history looking for historical API keys that might not have been rotated. In order to purge that information from git, you then have to go re-write the commit graph from the point of the key's insertion (with it removed) all the way to the present. It's not impossible to do, it's just a major pain.