Hide historical (private) commits in public repositories on bitbucket

Andrew Law November 25, 2015

I've developed some code over the past couple of years using an in-house git setup. The project has evolved and stuff that was initially intended to be a small-scale, internal code base has now become something that we want to publish. However, I don't want all the gory details being exposed to the world plus dog. I would like to be able to selectively push code to the public repository such that forks of that only ever see that code that we want to be available. That is - to all intents and purposes - the code from now onwards.

 

Moving forwards, I would also like to be able to control which bits of developed code get included into the public repository in a similar manner i.e. I might make a number of changes on my local copy but only want that to be seen as a single, atomic commit in the public version.

 

Is this possible?

 

FWIW - I am quite comfortable about getting my previously local-only git repository to talk to and synchronise with the BitBucket-hosted repository but that shoves everything across from what I can see.

 

Thanks in advance for any assistance you can provide. If not, thanks for reading this far anyway.

3 answers

1 accepted

2 votes
Answer accepted
Tim Crall
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
November 25, 2015

Git isn't really well designed to do what you're trying to do.

You could solve your first problem by just creating a new repo and copying your source code into it, adding, and committing.  But if you then pulled updates in your private repo into that public repo, the history would come with it.  Potentially you could just copy source into the private repo and commit it there every time you did want to publish changes, but that's a little more manual than you might like.

If you don't really need your own history in your working repo either, you could copy the source into the newly created repo, clone that repo to create a new working repo, and use rebase to squash commits on your branches (you can google this and find plenty of information if you don't know how to squash commits) before merging them back to master (and obviously only push master to the remote repo).  You could obviously keep a separate copy of your original repo for historical purposes.  I think that might be your best bet.  Start with a clean repo representing the state of the code as it is now, and use squashing on feature branches as necessary moving forward so you only publish commits that you want to publish.

2 votes
evzijst
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
November 25, 2015

Basically what @Tim Crall said. Git and Mercurial do not really allow publishing partial histories. Shallow clones aside, every user has a full copy of everything and most of the system relies on that.

So if you find yourself in a situation where you want to "clean up" your history before sharing, you can do that by essentially rebuilding your entire repository, commit by commit, combining/collapsing multiple changes into a single commit and omitting files that shouldn't have been in the repo in the first place. This is done using the built-in git filter-branch command.

Caveat: this will change the SHA1 of every commit and so the result will appear to be an entirely different repo. If this is a repo that is currently on Bitbucket, GitHub, etc, all existing pull requests will break. Everyone who has a copy/clone of the repo will have to delete it and instead clone the rewritten repo. The old and new repos are not be used in tandem, as any pull between them will reintroduce all the stuff you wanted to get rid of.

There is a ton of documentation out there around use cases for filter-branch, including higher level tools built on top the that command.

0 votes
Andrew Law November 25, 2015

Thanks @Tim Crall and @Erik van Zijst for your helpful replies. I had got myself to the point where I thought that a separate, clean repository was going to be the only solution but it was great to have that confirmed.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events