My organisation is preparing to release an open-source version of our software using github, however I'm not sure the best way to approach this:
We have two branches master and release, master contains some proprietary components that we have decided not to release, and release contains the cleaned-up version that we want to distribute. The problem is, if we just push the release branch to github, the proprietary components can be retrieved by looking through the revision history.
I was considering creating a separate repository, copying the HEAD of relase into it, doing a git init, and pushing that repository to github. However, we want to retain the ability to cherry-pick certain patches from master into release in the future, and push those changes up to github.
Is there a way to do this without maintaining two separte repositories?
Thanks!
Update:
To be a little more specific, this is sort-of what our commit history looks like at the moment:
--- o - o - o - o - f - o - o - f - master
\
c - c - c - c - c - c - c - REL - f - f
Where 'o' are commits in the master, proprietary branch, 'c' are commits that remove things that should not be published (often not removing entire files, but reworking existing ones not to rely on proprietary components), and 'f' are fixes in master that apply to release as well, and so have been cherry-picked. REL is a tagged version of the code we deem safe to publish, with no history whatsoever (even previous versions of the release branch, since not all the proprietary material had been removed before the REL tag).