Question

At first: This is (hopefully) no duplicate of this or this.

The current status: I committed a file with credentials for an internal database to my Git repository. This was fine, as I used it only alone. Then my group started to clone, push and pull around in this project. We now have several Git repositories (one central and some developers).

The problem: We now want to give public access to the source code, and to the Git repository or at least let Git manage the details of others contributing to the code.

The question: What would be a good strategy to

a) remove the file with the credentials from the central or from all repositories, or

b) set up a new Git repository as kind of ‘interface’ to the outer world?

If choosing (b), how could we easily communicate changes back to the main repository?

Due to the already widespread distribution, we’d really like to not do a git rebase or a git filter-branch on each and every current repository.

Answer 1

Sorry, but you’re stuck with running git filter-branch if you want to delete the credentials from the main repository. See Removing sensitive data, written by the folks at GitHub.

Due to git’s design, there’s no way to force existing clones to delete the file from their respective histories.

You could sanitize a single branch and make it the basis for future development:

$ git checkout -b old-master master
$ git filter-branch ... master

Now you’d need to push the sanitized master to a new repo that contains only the clean master:

$ git push new-central master

Existing repos can add the new remote and git cherry-pick changes from their old branches over to the new clean master if necessary.

For the new repository, put some sort of barrier in place to prevent someone pushing sensitive data to it so you don’t have the same problem all over again. This barrier might be a human being who controls the new central repository and reviews all patches to decide what goes in.