2

I have a local repo that contains all the code for cloud deployment. This repo contains lots of sensitive files specific to the cloud. All these files have already been committed to a private remote repo hosted on the deployment cloud. Now I want some way to commit that code to a public repo while excluding all the sensitive data files. I was going through this but I think my situation is a little bit different. My current local repo already contains all the sensitive files which have not been added to .gitignore file. If I happen to create a public branch from the deployment branch like this:

deployment:       A ---> B ---> C ---> D
                   \      \      \      \
                    \      \      \      \
public:           -> A'  -> B'  -> C'  -> D'

Then, for the first iteration (A), I would have all those sensitive files in my repo once again. I would then have to do this to get rid of all those sensitive files, modify my .gitignore to exclude those files in future, and then push the public branch to remote.

However, I can't think of how this would go ahead in the future.

Should I be merging my public branch to the deployment? (I think NO)

When the deployment code is updated, how would I propagate those changes to the public branch? In that case, should I merge deployment branch with public?

Is there any simpler way to do all this?

Community
  • 1
  • 1
Rafay
  • 6,108
  • 11
  • 51
  • 71

1 Answers1

2

Can you 12 factor the application at all? In other words, can you move all the sensitive config data into environment variables or a single configuration file which is NOT checked in to version control? (You probably would check in a 'fake sample' version of that file, with fake data in it, as a template to use in creating the real config file.)

If you can do that, then you do the git-sensitive-data-removal dance once, and publish your code. Your deployment process will grab the config file from a well known location OUTSIDE the repository, or set environment variables, or something similar, as the last step of deployment.

bloy
  • 251
  • 1
  • 2
  • Based on some suggestions elsewhere, I have come up with maintaining two copies of the project. One for the deployment and the other for public viewing. Every time I commit to the deployment repo, I copy the changed files to the public repo and simultaneously commit them to the public one, such that deployment and public are synchronized with each other and no commit history is lost. Obviously, all this is happening via a script that excludes all sensitive files from being copied to the public repo. – Rafay Apr 16 '14 at 15:06