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.
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.
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.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot