title: Push a branch of a git repo to a new remote (github), hiding its history
body: <p>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:</p>
  
  <p>We have two branches <strong>master</strong> and <strong>release</strong>, <strong>master</strong> contains some proprietary components that we have decided not to release, and <strong>release</strong> contains the cleaned-up version that we want to distribute. The problem is, if we just push the <strong>release</strong> branch to github, the proprietary components can be retrieved by looking through the revision history.</p>
  
  <p>I was considering creating a separate repository, copying the HEAD of <strong>relase</strong> into it, doing a <code>git init</code>, and pushing that repository to github. However, we want to retain the ability to cherry-pick certain patches from <strong>master</strong> into <strong>release</strong> in the future, and push those changes up to github.</p>
  
  <p>Is there a way to do this without maintaining two separte repositories?</p>
  
  <p>Thanks!</p>
  
  <p>Update:</p>
  
  <p>To be a little more specific, this is sort-of what our commit history looks like at the moment:</p>
  
  <pre><code>--- o - o - o - o - f - o - o - f - master
               \
                c - c - c - c - c - c - c - REL - f - f
  </code></pre>
  
  <p>Where 'o' are commits in the <strong>master</strong>, 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 <strong>master</strong> that apply to <strong>release</strong> 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).</p>