How do I hide/encrypt portions of GIT history?

Question

I am going to be recruiting some developers for a project. I would like to continue using the git repo if possible, but I would like to not make part of the history accessible (via encryption) so that only I can have acceess to it. The reason is that there is certain proprietary information in the history that I cleaned out in the head, such as account passwords that I hardcoded into the app during development. I do not want any other developer to see this without some form of authentication.

The obvious solution is to create a new repo off of this head, but I'd like to keep the full history if possible because it has branches that I may want to use down the road.

unfortuantely I use those passwords everywhere and I don't want to give anyone even a hint as to my password choosing heuristics. — user805547, Nov 24 '12 at 15:44
git filter-branch is defintely the way to go to get exactly what you want. Although changing passwords and not reusing would also be a responsible decision. — Steve McKinney, Nov 24 '12 at 16:38

score 7 · Accepted Answer · edited May 23 '17 at 12:27

You cannot hide just a part of the history if a Git repository; due to the way Git works, with each commit including the hash of previous commits, in order use a Git repository you need to have the full history.

However, you do have a few options. One would be to start a new repository with the current contents, and keep your old repository around. You can then give anyone who needs access to the old history the old repository. You can still view the full history across both repositories. You do this by adding remotes for each of the old and new, then using git replace to attach the last commit of the old repo to the first commit of the new. See the answer to this question for more details.

Another option is to filter the history. You can use git filter-branch --tree-filter to run a script on each commit in your history, which replaces all instances of your passwords with something like "password". This will preserve the full history, though all of your commits will get new commit IDs. See the answer to this question for more details.

Both of these options will allow you to keep your full history, while not revealing your passwords. One thing to keep in mind if that they will change the actual commit IDs so you will need to make sure all of your working repositories are checked out from the new ones, not the old, or you could accidentally push the old history to one of your new repos. I would recommend changing any passwords that are in the old repo just in case, since once they are there, it may be easy to accidentally reveal them.

score 1 · Answer 2 · answered Nov 24 '12 at 15:21

This is not really possible because of the git data model. What you could try however:

Identify all the commits that deal with such sensitive data.
Do a git rebase -i for those commits (depending on your repo size, this interactive rebase can be as deep as thousands of commits) and put those commits on top of HEAD
Reset those commits
Push with force

(this will alter the history, but if done correctly could only affect the sha numbers)

You would need to do that for all the branches and this will really get out of hand quickly. That is why I would go with Gumbo's suggestion to change the passwords.

score 0 · Answer 3 · answered Nov 24 '12 at 14:52

0

I'm not sure this is the best solution, but if it were me, I'd create a new repo and do integrations across them. Github has gone a long way to make this easier.

answered Nov 24 '12 at 14:52

Eric Fleischman

1,168
6
8

How do I hide/encrypt portions of GIT history?

3 Answers3