Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>If you have a single repository where parts are intended to be public and parts are intended to be private, then you need to fundamentally change something in your repository setup. git tracks complete repositories, so you can either make a repository public or private, but not partly this and partly that.</p> <p>If you have both a repo with the "public" files and a repo with the "private" files, you can add a git hook to the "public" repo to automatically push commits, and just keep the private repo private.</p> <p>However, you are writing that you have a single repo containing both "public" and "private" files, so you need to split that into something "public" and something "private in some way.</p> <p>You have a number of options to solve this situations:</p> <ol> <li><p>Split out the "public" folder into its own repository which you will push to github. This will rewrite the history of the "public" folder a little. I will outline this in more detail below.</p></li> <li><p>Create a branch that only concerns the "public" folder, and only publish that branch. This is risky in the "accidentally push, i.e. publish, private stuff" sense, and outright impossible or at least quite difficult to do if you have any commits that touch both "public" and "private" files, so I would advise against this option, and will not write more about it.</p></li> </ol> <p>For splitting off the "public" folder into its own repository, create a new "public" branch off your "combined" branch, and use <a href="http://git-scm.com/docs/git-filter-branch" rel="noreferrer"><code>git filter-branch</code></a> on it to make the new "public" branch contain only stuff from the "public" folder. The "Examples" section shows just the right --subdirectory-filter example). Then you will have both your old "combined" branch with both the "public" folder and the private stuff in it, and the new "public" branch with only the "public" folder.</p> <p>Be aware that e.g. the commit messages in the new "public" branch still might contain "private" information. So you should go through all the commit messages, scan them for private information, and possibly redact out that private information, e.g. with <a href="http://git-scm.com/docs/git-rebase" rel="noreferrer"><code>git rebase -i</code></a>.</p> <blockquote> <p><strong>Update:</strong> [The subsequent push of <em>only</em> the "public" branch and nothing else will probably not transfer any other information, so this repo cleanup is probably not needed.] If you needed to do any redactions, you will want to remove the old unredacted revs from the repo using <a href="http://www.kernel.org/pub/software/scm/git/docs/git-gc.html" rel="noreferrer"><code>git gc</code></a> (probably with the <code>--prune=0</code> and <code>--aggressive</code> options - but I can't find the SO answer with more info about that).</p> </blockquote> <p>Now your "public" branch is ready for publication. To make sure it only contains the "public" information, you can push it into a new empty local bare repo, examine the content of that to verify all refs have no private information. After you are satisfied, you can push the "public" branch to a new empty repo on github. The repo on github will then ONLY contain the "public" branch, which you should probably name "master" on the github repo.</p> <p>Your local repo with the "combined" branch still contains both public and private information directly, and has no connection to the new "public" github repo whatsoever.</p> <p>Now you <em>could</em> rewrite the "combined" branch's history to just contain the non-public bits, but that would sacrifice all connections between the state of "public" and "private" files during all of the history, so repeatable builds of old stuff would become close to impossible. Therefore, I suggest to leave the "combined" branch's history alone, and just remove the "public" folder from it in a new commit.</p> <p>If the integration between your private and your public files is very tight and version dependent, you can use <a href="http://git-scm.com/docs/git-submodule" rel="noreferrer"><code>git submodule</code></a> to add a specific version of the "public" repo from github into your private repo. A new submodule folder named just like the former "public" folder will minimize the changes to your private stuff, as then all "public" files will be in their old path. Note that the submodule folder will not update automatically when something has been pushed to the github. You might work around that by adding a git hook to your local submodule folder which would update the submodule information in the "combined" repo.</p> <p>If the integration between your private and your public files is more loose, you can also treat the public files like any external third-party project and integrate it into your private stuff in the way anybody else would integrate it, i.e. like any external piece of software your "private" software depends on.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload