We use plain GPG-encrypted files stored in our version control system (git/svn). The files get encrypted with all the public keys of the users who have access to these files, and can be decrypted with their private keys then. Not perfect, but works.
We do this too. The trick is making sure everyone keeps everyone else's public keys up to date and signed in their clients, because if you edit the file and re-encrypt it for everyone else to read, it's easy to overlook that GPG ignored one of the recipients due to you not having their key signed, etc.
None of us are fluent enough in GPG practices to do this stuff off the top of our heads, though, so our management of these files involves a lot of rote "here's how to re-encrypt the file" or "here's how to import the new guy's key" instructions. It's pretty clunky.
you mean you have for N users N copies of the file, each encrypted with a different key, or one file that is encrypted with N keys and then you need N keys to decode?
You can encrypt a file to N users in GPG with only one output file, and require only one of the corresponding private keys to decrypt. More information here [0]; TLDR, it encrypts with a symmetric key then includes the symmetric key encrypted with the public key of each recipient.
You've one copy of the file, encrypted with N public keys. Each of the corresponding private keys can decrypt the files.
Assuming you've all the public keys in your keychain, then for each key you pass "-r <email>" for the encryption, like "gpg -e -r foo@bar.com -r baz@bar.com plain.txt", and for decryption you do something like "gpg --output plain.txt -d plain.txt.gpg".
