Ar teisinga „Git“ darbo eiga, skirta OS ir asmeniniam kodui?

Turiu uždarojo šaltinio projektą, kuris remiasi mano atviro kodo struktūra. Noriu žinoti, kaip turėčiau struktūrizuoti savo darbo eigą. Žemiau yra mano spėjimas, naudojant git su submoduliais.

  • Sukuriu viešą github struktūros saugyklą su submoduliais, kurie yra atskira git repozitorija.
  • Aš nusipirkau „mikro“ paskyrą „github“ ($ 7), todėl galiu turėti privačią repo.
  • Kuriu privačią repo ir klonuoju viešosios struktūros saugyklą.

Čia galiu atlikti pakeitimus:

  • Mano asmeninis kodas ir spustelėkite mano asmeninį atpirkimą github
  • Atidarykite „Wireframe“ kodą ir spragtelėkite mano privačią „github“ repeticiją, tada pateikite perkėlimo užklausą iš viešosios struktūros ..? Arba, kaip ji veiks?

Kaip elgtis su atpirkimo sandoriais, kuriuose yra uždaryti ir atviri šaltiniai ir submoduliai. Šiuo metu atrodo, kad noriu pasiekti šį tikslą turiu išlaikyti du atskirus kodus.

Aš ieškau geriausio atsakymo, kuris gali padėti kažkam gana naujam, kad būtų supaprastintas darbo su kodu baze, kuris yra pusiau atviras ir pusiau privatus, procesas. Vienas geras dalykas yra tai, kad kiekvienas aplankas yra privatus arba viešas, todėl nėra jokio susirūpinimo dėl privačių ir viešų failų dalijimosi, tačiau kai kurie privatūs aplankai gali būti vieši!

Kitas pavyzdys, kurį galėčiau pateikti, būtų naudoti „zendframework“, kad sukurtumėte savo privačios įmonės svetainę, tuo pačiu metu sugebant (ir, galbūt, pataisyti) į „zend-repo“. Ir taip pat traukia ir stumia jūsų privačią svetainę zendframework.

Pavyzdžiui, įsivaizduokite katalogų struktūrą taip:

 /private_folder /public /public_folder /public_folder2 /private_folder 

Galbūt aš paprašysiu dviejų būdų, kaip su jais susidoroti viename bendro atpirkimo kataloge. Galbūt tai nėra lengvas būdas, ir turiu juos atskirti ir padaryti visus viešuosius pleistrus viename, o tada tiesiog įdėti į savo privačią repo. Žinoma, tai reiškia, kad jei esu viduryje dirbdamas su tam tikru privačiu kodu, turėsiu palikti šį repo ir atidaryti atidarytą failą ir įvesti pataisytą kodą, tada grįžti į privatųjį, sujungti ir tęsti darbą su privačiu kodu.

10
04 февр. Xeoncross nustatė 04 vasario mėn 2010-02-04 01:03 '10, 1:03 2010-02-04 01:03
@ 6 atsakymai

Aš rekomenduoju ne naudoti git submodules, bet 2 skirtingas saugyklas, kurios nėra prijungtos prie github.

Galite kurti tarpusavio ryšius naudodami simbolines nuorodas į išgautas kopijas, kurios yra paprastos ir paprastos. Simbolinės nuorodos turi būti sukurtos tik vieną kartą kiekvienai vietai (gamyba, plėtra, kolegos).

Privalumas yra tas, kad niekas neturėtų dėti papildomų pastangų studijuoti ir palaikyti git submodulius, ir jūs vengiate jo keliamos rizikos ir sudėtingumo.

Tai galite padaryti įrašydami darbo ir privačios „Git“ saugyklos kopiją kažkur vietiniame kompiuteryje:

 /repos/myproject-os /repos/myproject-priv 

Tada galite sukurti savo katalogo struktūrą, kurioje projektas gyvens ir dirbs kitur šiame kompiuteryje (ne viduje / repo / medyje), ir sukurkite simbolius jūsų naudojamiems pakatalogiams:

 ln -s /repos/myproject-os/dir1 /wrk/myproject/base/dir1 ln -s /repos/myproject-os/dir2 /wrk/myproject/base/dir2 ln -s /repos/myproject-priv/dir1 /wrk/myproject/base/dir3 ln -s /repos/myproject-priv/dir2 /wrk/myproject/base/someother/dir4 mkdir /wrk/myproject/base/config mkdir /wrk/myproject/base/tmp 

Taigi, kapinyno struktūra visada yra švari ir gali susimaišyti ir tvarkyti abiejų saugyklų katalogus taip, kaip norite, ir jūs taip pat turite vietos vietinėms konfigūracijoms arba laikiniesiems failams, kurie nėra saugyklos dalis.

Jūs vykdytumėte git'o įsipareigojimus ir viską iš medžio / repo /, ir jūsų projektas prasidės ir redaguosite failus iš / wrk / tree. Atkreipkite dėmesį, kad .git direktyva, kurioje git duomenų gyvena, nebus pasiekiama iš / wrk / tree, nes nurodote tik subdirectories (arba galbūt atskiri failai iš šakninio katalogo).

2 dalis. Jūs sakote, kad norite įsitikinti, kad netyčia įvedėte uždarą kodą į bendrą saugyklą. Galite nustatyti papildomą git saugyklą tarp savo darbo operacinės sistemos saugyklos ir „github“ saugyklos, sakykime, kad įdėjote / repos / gatekeeper, tada jūsų medis atrodo taip:

 /repos/gatekeeper/myproject-os /repos/myproject-os /repos/myproject-priv 

Kiekvieną kartą paspaudus / repos / myproject -os, jis eina į / repos / gatekeeper / myproject -os. Bet iš / repos / myproject -priv, spustelėję tiesiogiai savo privačią github repeticiją.

Taigi jūs turite tą patį darbų srautą / repos / myproject -os ir repos / myproject-priv, ir jums nereikia nerimauti. Kartais, kai norite keisti tikrą savo OS kodo bazę, eikite į / repos / gatekeeper / myproject -os ir spustelėkite ten github.

Prieš tai galite atlikti papildomą kodo peržiūrą ir išnagrinėti skirtumus, kad įsitikintumėte, jog tik tai, ką tikrai norite, bus viešai prieinama.

Jei jums reikia papildomo saugumo, / repos / gatekeeper / myproject -os taip pat gali būti kitoje mašinoje arba net kitoje vietoje.

5
12 февр. Atsakymą pateikė Sven Larson , vasario 12 d. 2010-02-12 02:03 '10 - 02:03 2010-02-12 02:03

Apibendrinant rekomenduoju šią darbo eigą:

  • laikykite jį paprastu; turėti vieną darbo kopiją kiekvienai saugyklai (nenaudokite git submodulių)
  • Naudokite savo kalbos priemones pakuotei savo infrastruktūrą.
  • diegimo scenarijai arba lengvi įrankiai, skirti greitai arba automatiškai keisti kontekstą.

Aš anksčiau naudoju git submodulius. Nemanau, kad jie tinka jūsų naudojimui. Dideli trūkumai, kurie man šokinėja, yra šie:

  • Jis padeda valgyti jūsų šunų maistą, kai statote (arba pašalinate) rėmelius. Ar tikitės, kad jūsų sistemos naudotojai taip pat sukonfigūruotų „git“ submodulius, kai jie naudoja jūsų sistemą? Manau, ne.
  • Yra tam tikra rizika, kad atsitiktinai paskelbsite savo šaltinio kodą atviro kodo aplinkoje.
  • „Git“ submoduliai per pastaruosius metus gerokai pagerėjo, tačiau jie vis dar gana silpni. Net kompetentingi bitters gali kovoti su submoduliais.

Čia yra vienas iš sub-subjektų, kuriuos pripažįstu, nėra toks aiškus: „Kuri darbo eiga palengvina eiti pirmyn ir atgal tarp OSS infrastruktūros ir privačiojo projekto?“

  • Yra tam tikras noras naudoti submodulius ir turėti abu projektus tame pačiame medyje. Tai pagreitins jus, galbūt teksto redagavimo metu, bet tikriausiai lėtins jus (arba sukels daugiau klaidų, nei įprasta), kai reikia padaryti ir spustelėti.

  • Yra tam tikras prašymas atskirti projektus. Kontekstinis jungiklis (iš vieno teksto redaktoriaus >

Vienas iš jų, kurį nustatėte su savo darbo kopijomis, norėsite sužinoti savo darbo dieną. Žinoma, tai priklausys nuo jūsų kalbos. (Pavyzdžiui, Ruby galite OSS infrastruktūrą pakuoti kaip brangakmenį, sukurti ją ir tada priklausyti nuo jūsų asmeninio kodo.) Nepriklausomai nuo to, ką pasirinkote, nustatykite kai kuriuos scenarijus (arba galbūt redaktorių nuorodas), padėti greitai kurti bibliotekas (arba paketus), galbūt net automatiškai keičiant failus, kad galėtumėte lengvai atsimesti tarp savo infrastruktūros ir projekto.

1
09 февр. Atsakymas David J. 09 vasaris 2010-02-09 09:03 '10, 9:03, 2010-02-09 09:03

Vietinėje saugykloje galite turėti „viešą“ ir „privatų“ filialą. Spustelėjus, kiekvienas filialas pereina į atskirą nuotolinį saugyklą (žr. Sintaksę „git push“). Tada galite laisvai sujungti iš visuomenės į asmeninį.

Esu įsitikinęs, kad pasirinktus pakeitimus galite derinti iš privačių į visuomenę, nors turėčiau ją ieškoti.

1
04 февр. Atsakymą pateikė Dietrichas Eppas 04 Feb. 2010-02-04 01:12 '10 ne 1:12 2010-02-04 01:12

git submodules leidžia jums nustatyti konfigūraciją (žr. šį klausimą ), ty nuorodą į kito komponento įvykdymą (kitame repo).

Jūs galite sukurti abu kodus (savo ir submodulius) toje pačioje repo dalyje, bet kai kalbate apie kelis privačius katalogus savo viešai prieinamame kode, tai sukelia subtrijų susijungimo strategiją .
Tai leis jums tvarkyti savo katalogus (privačius ir viešus) kaip vieną natūralų darbo medį.

Ir norėčiau geriau valdyti pasaulinio repo paspaudimo ir ištraukimo dalis tam tikrame, norėčiau rekomenduoti „ git script“ subtree įrankį .

1
08 февр. Atsakymą pateikė VonC 08 Feb. 2010-02-08 10:27 '10, 10:27, 2010-02-08 10:27

Čia pateikiami du būdai:

  • Galite naudoti tos pačios git saugyklos filialą. Savo privačiame atpirkime sukurkite filialą su nuoroda į viešąjį atpirkimo sandorį ir apdorokite abu.

  • Jei jūsų privačiame projekte naudojami komponentai yra jūsų viešai prieinamos medžiagos projektas, turite naudoti submodulius. Submodulio apdorojimas yra ankstyvame git versijos 1.6.6 versijoje, tačiau jis gali būti naudingas kaip jūsų subprojektas.

Man atrodo, kad jūs negalite prarasti, jei projektas yra duoklė kiekvienam projektui, taigi, jei turite tai aišku, tada, nesvarbu, ką pasirinksite, jis veiks !!!!!! Be to, git lengva.

0
12 февр. atsakymas pateikiamas erick2red 12 vasario 12 d. 2010-02-12 02:40 '10, 2:40, 2010-02-12 02:40

Padaryti viešą atpirkimo submodulį privačiame. Kai paspausite, nepamirškite, kad juos reikia stumti. Be to, nepamirškite pačiam patikrinti submodulį privačiame repo, taigi jis stebi, kokius pakeitimus jis naudoja.

-1
04 февр. Atsakymą pateikė Andrew McGregor 04 vasaris. 2010-02-04 01:45 '10 ne 1:45 2010-02-04 01:45

Kiti klausimai apie „ žymes arba Užduoti klausimą