StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

POSetting Up a Public Git Repo
text
Body
copied!<p>my team has been working on a platform for the past few months, and we're ready to release it to the rest of the firm. We'd like to follow the "integration manager workflow" found here: <a href="http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows" rel="nofollow">http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows</a>.</p> <p>We have some proprietary code in our team repository that we'd rather not share with the rest of the firm, and so must create a "stripped-down" version of our current team repository. I'm looking at doing the following:</p> <ol> <li><p>clone our existing team repository to create the "integration manager repo"</p></li> <li><p><code>rm</code> all the proprietary files </p></li> <li><p><code>commit</code> the rms </p></li> <li><p><code>rebase -i --root</code> to squash all commits and prevent rewinds </p></li> <li><p><code>clone --bare</code> the "integration manager repo" to create the "blessed repo"</p></li> </ol> <p>Now, being relatively inexperienced with Git, a couple of things are uncertain to me about this approach:</p> <ol> <li><p>Can I still do a pull from the "blessed repo" into our team repo?</p></li> <li><p>Assuming that I can do #1, I think the rms will get pulled, deleting all of our proprietary files. I need Git to view our team repo's more-advanced state as a child state of the blessed repo state. Is this something that I can do with rebase?</p></li> <li><p>As we continue to work on the platform, we will commit to our team repo a mixture of "public" features and proprietary features. What is the best way to push only the "public" features? Can I <code>rebase</code> to change the order of commits so that all "public" feature commits are at the front of the commit history, and then git push only up to the SHA of the latest "public" feature commit?</p></li> </ol> <p>Thanks in advance for the help... I wanted to run this by some more experienced Git users before making such big changes.</p> <p><strong>UPDATE</strong> Sorry, I wasn't being clear... steps 2, 3 and 4 were all meant to be applied to the "integration manager repo". In any case, I read up some more on <code>rebase</code> and decided that it wasn't a good idea to <code>rebase</code> our team's shared repository every time we made a "public" change.</p> <p>What I ended up doing instead of steps 2, 3 and 4 was <code>rm</code> the .git folder in the "integration manager repo", and start over fresh with <code>git init</code>. Then I pulled from this fresh "integration manager repo" and merged with our team's repo, using the <code>-s ours</code> flag since our team's version is a superset. Now our team repo and the public repo have a common commit. I created a "public" branch in our team repo and pointed it to this common commit. Going forward, whenever we make a public change, we will need to cherry-pick it into this "public" branch and then pull the public branch into the "integration manager repo".</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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