Reputation: 2728
I know I should put the file containing secret AWS keys in a .gitignore, but then the user on github is forced to reconstruct my constants code containing AWS keys ( a swift struct with static let's). Is there something that would let me substitute a different file when I push? Is there a better way to do this?
Clarification: I am not concerned with sharing AWS keys with other developers. In my situation each developer is independent and can use their own AWS keys.
What I am trying to accomplish is to have a local single development environment where I can develop and test a swift app on Xcode (without changing the keys every time I commit), and yet still be able to push to public GITHUB.
When someone clones the repository, I want them to be able to build after only updating the dummy key values, but I don't ever want my secret keys to be available in any way on GITHUB
Upvotes: 0
Views: 608
Reputation: 5104
You could add your keys to a plist, which is added to your .gitignore file.
That way you don't have to keep resetting those swift variables every time you want to commit, it just pulls from the local plist. Most of my projects also use this plist driven approach to target different schemes. I'll create a 'debug' dictionary for my pre-production api keys, and a 'release' dictionary for my production api keys. This has the added bonus that you can keep production api keys from temp workers if you really wanted to. Works for me, and is very neat.
Yes, you still have to get the other developer that plist file somehow; but there are plenty of ways to do that in an encrypted fashion... it's just a text file.
Upvotes: 3
Reputation: 36352
Most Projects faced with that problem simply substitute dummy values in places of actual keys.
Git makes it especially easy to keep this working – as long as you don't change the dummy line, every git pull / (git fetch + git merge) will preserve the user's line if he's commited the file once.
Upvotes: -1