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:
clone our existing team repository create "integration manager repo"
rm
proprietary filescommit
rmsrebase -i --root
squash commits , prevent rewindsclone --bare
"integration manager repo" create "blessed repo"
now, being relatively inexperienced git, couple of things uncertain me approach:
can still pull "blessed repo" our team repo?
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?
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 rebase
d), may able cherry-pick
them. of course, conflicts part of routine.
as you've squashed rm
s, blessed repo never see rm
s 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
Post a Comment