Setting Up a Public Git Repo -


my team has been working on platform past few months, , we're ready release rest of firm. we'd follow "integration manager workflow" found here: http://git-scm.com/book/en/distributed-git-distributed-workflows.

we have proprietary code in our team repository we'd rather not share rest of firm, , must create "stripped-down" version of our current team repository. i'm looking @ doing following:

  1. clone our existing team repository create "integration manager repo"

  2. rm proprietary files

  3. commit rms

  4. rebase -i --root squash commits , prevent rewinds

  5. clone --bare "integration manager repo" create "blessed repo"

now, being relatively inexperienced git, couple of things uncertain me approach:

  1. can still pull "blessed repo" our team repo?

  2. assuming can #1, think rms pulled, deleting of our proprietary files. need git view our team repo's more-advanced state child state of blessed repo state. can rebase?

  3. as continue work on platform, commit our team repo mixture of "public" features , proprietary features. best way push "public" features? can rebase change order of commits "public" feature commits @ front of commit history, , git push sha of latest "public" feature commit?

thanks in advance help... wanted run more experienced git users before making such big changes.

update sorry, wasn't being clear... steps 2, 3 , 4 meant applied "integration manager repo". in case, read more on rebase , decided wasn't idea rebase our team's shared repository every time made "public" change.

what ended doing instead of steps 2, 3 , 4 rm .git folder in "integration manager repo", , start on fresh git init. pulled fresh "integration manager repo" , merged our team's repo, using -s ours flag since our team's version superset. our team repo , public repo have common commit. created "public" branch in our team repo , pointed common commit. going forward, whenever make public change, need cherry-pick "public" branch , pull public branch "integration manager repo".

you won't able pull changes blessed repo team 1 (as they're rebased), may able cherry-pick them. of course, conflicts part of routine.

as you've squashed rms, blessed repo never see rms performed @ all. so, whenever cherry-pick commits team repo, have files never change (and troubles can generate).

the problem publishing changes team repo blessed 1 :)

if (well, time ago in similar position), think in creating kind of script moves changes 1 repository other. when going blessed 1 team one, make warning related rm'ed files want see based on files changed (if any). when going back, exclude changes rm'ed files.

anyway, don't think idea @ all. triple check before going wild - maybe start babysteps?

good luck :)


Comments

Popular posts from this blog

ios - UICollectionView Self Sizing Cells with Auto Layout -

node.js - ldapjs - write after end error -

DOM Manipulation in Wordpress (and elsewhere) using php -