blogul GitHub

În cele din urmă, orice proiect software interesant va depinde de un alt proiect, bibliotecă sau cadru. Git oferă submodule pentru a ajuta în acest sens. Submodulele vă permit să includeți sau să încorporați unul sau mai multe depozite ca sub-folder în alt depozit.pentru multe proiecte, submodulele nu sunt cel mai bun răspuns (mai multe despre acest lucru mai jos) și, chiar și în cel mai bun caz, lucrul cu submodule poate fi dificil, dar să începem prin a privi un exemplu direct.,

adăugarea unui submodul

Să presupunem că lucrați la un proiect numit Slingshot. Aveți cod pentru y-shaped stick și un rubber-band.

flickr fotografie împărtășită de tineri@arta sub o licență Creative Commons ( DE ) licența

În același timp, într-un alt depozit, ai un alt proiect numit Rock—este doar un generic rock bibliotecă, dar cred că ar fi perfect pentru Praștie.

puteți adăuga rock ca un submodul al slingshot., În slingshot depozit:

În acest moment, veți avea un rock folder în interiorul slingshot, dar dacă ați fost de a arunca o privire în interiorul acel folder, în funcție de versiunea de Git, s-ar putea vedea … nimic.,

versiunile mai Noi de Git va face acest lucru automat, dar versiunile mai vechi vor avea nevoie pentru a spune în mod explicit Git pentru a descărca conținutul rock:

Daca totul arata bine, poți comite această schimbare și veți avea un rock folder în slingshot depozit cu tot conținutul din rock depozit.,

Pe GitHub, rock pictograma folder va avea un pic de indicator arată că acesta este un submodul:

Și faceți clic pe rock folder va duce la rock depozit.

asta este! Ai încorporatrock depozit în interiorulslingshot depozit. Puteți interacționa cu tot conținutul din rock ca și cum ar fi un folder în interiorul slingshot (pentru ca este).,

Pe linia de comandă, Git comenzi emise de slingshot (sau la oricare dintre celelalte dosare, rubber-band și y-shaped-stick) va opera pe „părinte depozit”, slingshot, dar îți poruncește problema din rock folder va funcționa doar pe rock depozit:

Aderarea la un proiect utilizând submodule

Acum, să zicem că ești un nou colaborator aderarea Proiect Praștie., Ai începe prin rularea git clone pentru a descărca conținutul slingshot depozit. În acest moment, dacă ar fi să aruncați o privire în folderul rock, nu ați vedea … nimic.

Din nou, Git se așteaptă să-i cerem în mod explicit să descarce conținutul submodulului., Puteți folosi git submodule update --init --recursive aici la fel de bine, dar daca esti clonarea slingshot pentru prima dată, puteți folosi o versiune modificată clone comandă pentru a-ți descărca totul, inclusiv orice submodule:

Trecerea la submodule

Acesta poate fi un pic dificil să ia existent subfolder și să-l transforme într-o dependență externă. Să ne uităm la un exemplu.

sunteți pe cale să începeți un nou proiect—o cutie magică de tip roll-back–care are nevoie și de un rubber-band., Să luăm rubber-band ai construit-o pentru slingshot, split-l intr-un stand-alone depozit, și apoi încorporați-l în ambele proiecte prin submodule.

puteți lua totul din dosarul rubber-band al proiectului Slingshot și să îl extrageți într-un nou depozit și chiar să mențineți Istoricul comiterii.

Să începem prin extragerea conținutului folderului rubber-band din slingshot., Puteți folosi git filter-branch pentru a face acest lucru, lăsându-te cu doar angajează legate de rubber-band. git filter-branch comanda va rescrie istoria depozit, făcându-l arate ca în cazul în care rubber-band folder a fost propriul depozit toate împreună. Pentru mai multe informații despre git filter-branch, consultați acest articol.

primul pas este de a face o copie de slingshot să lucreze de pe—the-scopul final este de rubber-band de a fi propriul său depozit, așa că lăsați slingshot cum este., Puteți folosi cp cu -r recursiv copiați întregul slingshot folder într-un folder nou rubber-band.,

Se pare ca rubber-band este doar un alt slingshot, dar acum, din rubber-band depozit, run git filter-branch:

În acest punct, vei avea un folder rubber-band, care este un depozit care seamănă cu un fel de Proiect Praștie, dar ea are doar fișierele și comite de istorie din rubber-band folder.,

Deoarece ai copiat asta de la slingshot, noul depozit va trebui în continuare orice urmărire la distanță ramuri de configurare atunci când a fost slingshot. Nu doriți să împingeți rubber-bandînapoi peslingshot. Vrei să împingă acest lucru la un nou depozit.

creați un nou depozit pentru rubber-band pe GitHub, apoi actualizați telecomanda pentru rubber-band., Presupunând că ați fost de asteptare de la distanță origin, ai putea:

Apoi puteți publica noi „generic banda de cauciuc modulul” cu git push.,

Acum, că te-ai despărțit rubber-band în propriul depozit, trebuie să ștergeți vechiul rubber-band folder din slingshot depozit:

Apoi actualizați slingshot pentru a utiliza rubber-band ca un submodul:

Cum am văzut mai înainte, când am fost adăugarea rock, acum avem un depozit în depozit., Trei depozite, în fapt: „mamă” depozit slingshot, plus două „sub” magazii, rock și rubber-band.

În plus, dacă ne-am arunca cu capul înapoi în slingshot‘s istorie, vom vedea angajează inițial am făcut în rubber-band pe vremea când era un folder—stergerea folderului nu șteargă din istorie., Acest lucru poate fi, uneori, un pic confuz—de la rubber-band „copil” depozit are o copiate și modificate versiune de cei vechi slingshot se angajează, se poate simti uneori ca ai avut un „deja vu”.

din Pacate, orice colaborator care trage slingshot în acest moment va avea un gol rubber-band folder., Ați putea dori să reamintesc colaboratorii dumneavoastră pentru a rula această comandă pentru a se asigura că acestea au toate submodul de conținut:

de asemenea, Veți dori să adăugați rubber-band submodul să magic roll-back can. Din fericire, tot ce trebuie să faceți este să urmați procedura de mai devreme ai folosit când ai adăugat rock și slingshot, în „Adăugarea unui submodul.”

sfaturi privind utilizarea submodulelor (sau nu)

• înainte de a adăuga un depozit ca submodule, verificați mai întâi dacă aveți o alternativă mai bună disponibilă., Submodulele Git funcționează suficient de bine pentru cazuri simple, dar în aceste zile există adesea instrumente mai bune disponibile pentru gestionarea dependențelor decât ceea ce pot oferi submodulele Git. Limbile moderne, cum ar fi Go, au sisteme de gestionare a dependenței prietenoase, conștiente de Git, încorporate încă de la început. Alții, cum ar fi rubygems Ruby, nod.JS ‘npm, sau Cocoa’ s Cocoa și Carthage, au fost adăugate de comunitatea de programare. Chiar și dezvoltatorii front-end au instrumente precum Bower pentru a gestiona bibliotecile și cadrele pentru JavaScript și CSS din partea clientului.
• amintiți-vă că Git nu descarcă conținutul submodulului în mod implicit., Dacă adăugați un submodul la un proiect existent, asigurați-vă că cineva care lucrează la proiect știe de care au nevoie pentru a rula comenzi ca git submodule update și git clone --recursive pentru a se asigura că acestea obține tot ce—aceasta include orice implementare automată sau servicii de testare care ar putea fi implicate în proiect! Vă recomandăm să utilizați ceva de genul „Scripturilor noastre pentru a le conduce pe toate” pentru a vă asigura că toți colaboratorii și serviciile au acces la același conținut de depozit peste tot.
• Submodulele necesită să echilibrați cu atenție consistența și confortul., Configurarea folosită aici preferă puternic consistența, cu prețul unui mic confort. În general, este mai bine să aveți submodulele unui proiect blocate la un anumit SHA, astfel încât toți colaboratorii să primească același conținut. Dar această configurare face, de asemenea, dificil pentru dezvoltatorii din depozitul „părinte” să contribuie cu modificări înapoi la depozitul submodule.
• rețineți că colaboratorii nu vor vedea automat actualizări ale submodulelor—dacă actualizați un submodul, poate fi necesar să le reamintiți colegilor să ruleze git submodule update sau probabil că vor vedea un comportament ciudat.,
• gestionarea depozitelor dinamice, cu evoluție rapidă sau puternic co-dependente cu submodule poate deveni rapid frustrant. Acest post a fost axat pe relații simple, relativ statice părinte-copil depozit. O viitoare postare de urmărire va detalia câteva strategii pentru a ajuta la gestionarea fluxurilor de lucru submodule mai complexe.

lectură suplimentară