Asymmetric encryption means that you use one key to encrypt, and ONLY the matching other key can decrypt. You don't use YOUR public key to encrypt a message you want to send to somebody. You use THEIR public key. The message will ONLY be able to be decrypted by THEIR private key.
If they wanted to send a response to you, they use YOUR public key, creating a message that can only be decrypted by YOUR private key.
Storing a PGP private key in a revision control system does not, in and of itself, pose any significant security issues. Storing the private key in a local, private (unpublished) git repository should have no significant security implications versus storing the private key on the same computer but outside of any git repository.
The only issue I can think of that comes from storing the private key in a version-controlled manner is that unless you can somehow destroy the older revisions, key passphrase changes buy you far less protection than they otherwise might.
What can come with its own set of security implications is storing a private key in such a way that someone else might be able to get access to the key file. In such a situation, all that stands between an attacker and your key is the strength of its passphrase.
Recognizing that storage security isn't perfect, and even more so in the modern environment where people regularly back up to cloud services (which literally translated means "someone else's computer"), we usually protect our secret keys with passphrases. I trust that, even if you are running for example gpg-agent, you are doing the same.
The bottom line is that, as long as your passphrase is good, even storing a copy of the encrypted key file on someone else's computer should be relatively safe.
However, that's a pretty big if: most peoples' passwords or passphrases are rather lousy as far as computerized attempts at cracking them go. GnuPG goes to quite some length to try to work as well as it can with what you give it, but for solid data protection, you need a good passphrase, and you need to set it before importing the private key into the git repository. After the key has been imported, an attacker could in principle attack any version of it, and if they have reason to believe that a particular revision has a lower-quality passphrase will likely go for that. For that reason, make sure that you pick the passphrase with care. I have written up a small primer on how to handle passwords, including suggestions on how to choose passwords or passphrases that you need to be able to remember, which you may find useful.
Best Answer
I have used this method to encrypt a file
gpg -r your.email@example.com -e ./filenameand this will create filename.gpg which is the encrypted content.And to decrypt you do
gpg -d filename.gpgIn regards to the email requirement - when you generate a new key using
gpg --gen-keyyou will be required to enter an email address and it will create a public/privatey key pair based on that email address. You simply need to use that same email address. It does not send it, it simply tell gpg which private/public key pair to use (and the identifier is the email address)