Ideally, I would separate the data from the code in the scripts you're writing. That means to store all your assets outside of the repository, probably in packages specific to your distribution (dpkg, RPM, etc.), signed using GPG. This will make your scripts more abstract, flexible and easier to maintain, but you will have to learn how to create packages for your distribution.
If you insist on using a key shared between all your servers, at least encrypt it and ask for a password during installation time. This way the password will not be stored in the repository and can be changed when necessary.
No matter how secure your repository is, you need to keep in mind that if you keep the private keys unencrypted in your (D)VCS, they will be distributed to all the people that will be developing as well. That, in my opinion makes containing any information leaks much more difficult. In this case, consider the situation when a member of your team leaves, you will need a way to revoke and issue a new set of keys anyway.
I would not easily discard the possibility of generating a new keypair for each new server. I guess that distribution of the public keys is what bothers your, but it is not an unsolvable task. Depending on your installation script, the generated public key can be displayed during the process and added to the repository's access lists.
Are you planning on using some kind of configuration management or instrumentation system to bootstrap and configure the servers? If not, I would strongly suggest you consider using one instead of developing a set of scripts. They provide a lot of other added benefits to server management, not only for this task in particular. Puppet, chef, cfengine, salt, bcfg2 (and a few others) and even some remote instrumentation systems like Fabric and Ansible make the process of exporting a set of public keys quite easy and pain-free.