Hide historical (private) commits in public repositories on bitbucket

Andrew Law

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.

Tim Crall1

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.