3

I have a local project I have been working with for a while. In this project there are some configuration data that contains passwords. I now want to make this project public on Github and want to split up the configuration data and not check in the sensitive data as I should have done from the start. However even if a do this at HEAD the data is still available in the history of commits.

Is there a way to solve this problem or do I have to delete all old commit and only use the one latest clean commit in the public repo?

Between available options which is the most idomatic?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
user3139545
  • 6,882
  • 13
  • 44
  • 87

2 Answers2

3

There's a great Git feature called filter-branch. It allows you to recreate a Git history, applying a command at each step. In this case, you'd use it to delete your sensitive file:

git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch my/sensitive/file' HEAD

It's worth pointing out that as with all such Git magic, the newly rewritten branch will have a different "family tree" to original, so you won't be able to merge back and forth. In other words, anyone who was working on the original repo will need to fetch the new branch before committing any work.

jub0bs
  • 60,866
  • 25
  • 183
  • 186
N3dst4
  • 6,360
  • 2
  • 20
  • 34
2

git filter-branch is a good solution,

But bfg-repo-cleaner is a much faster solution than git filter-branch

enter image description here

CodeWizard
  • 128,036
  • 21
  • 144
  • 167