Am văzut multe aceste cuvinte în jurul discuțiilor despre Subversion (și presupun că depozitul general).
Am folosit SVN pentru proiectele mele în ultimii câțiva ani, dar nu am înțeles niciodată conceptul complet al acestor directoare.
Ce vor sa zica?
Hmm, nu sunt sigur că sunt de acord că eticheta lui Nick este similară cu o ramură. O etichetă este doar un marker
Portbagajul ar fi principalul corp de dezvoltare, provenit de la începutul proiectului și până în prezent.
Sucursala va fi o copie a codului derivat dintr-un anumit punct al trunchiului care este utilizat pentru aplicarea modificărilor majore la cod, păstrând în același timp integritatea codului din trunchi. Dacă schimbările majore funcționează conform planului, ele sunt de obicei fuzionate înapoi în portbagaj.
Eticheta va fi o punct în timp pe trunchi sau pe o ramură pe care doriți să o păstrați. Cele două motive principale pentru conservare ar fi că fie aceasta este o lansare majoră a software-ului, fie alfa, beta, RC sau RTM, fie acesta este punctul cel mai stabil al software-ului înainte de a fi aplicate revizuiri majore pe trunchi.
În proiectele cu sursă deschisă, ramurile majore care nu sunt acceptate în trunchi de către părțile interesate ale proiectului pot deveni baze pentru furcături -- de exemplu, proiecte total separate care au o origine comună cu alt cod sursă.
Ramurile și subarborele de etichete se disting de trunchi în următoarele moduri:
Subversion permite administratorilor de sistem să creeze scripturi hook care sunt declanșate pentru execuție atunci când apar anumite evenimente; de exemplu, efectuarea unei modificări în depozit. Este foarte comun ca o implementare tipică a depozitului Subversion să trateze orice cale care conține „/tag/” să fie protejată la scriere după creare; rezultatul net este că etichetele, odată create, sunt imuabile (cel puțin pentru utilizatorii „obișnuiți”). Acest lucru se face prin intermediul scripturilor hook, care impun imuabilitatea prin prevenirea modificărilor ulterioare dacă eticheta este un nod părinte al obiectului modificat.
Subversion are, de asemenea, funcții adăugate, începând cu versiunea 1.5, referitoare la „urmărirea îmbinării ramurilor”, astfel încât modificările efectuate către o ramură să poată fi îmbinate înapoi în trunchi, cu suport pentru îmbinarea incrementală, „inteligentă”.
Tags este adesea folosit pentru testarea și verificarea jaloanelor de către utilizatorul obișnuit. Acesta ar fi un loc bun pentru a pune și un prototip (doar câteva idei peste capul meu).
- person Jeff Noel; 26.10.2012
trunk. (*pentru detalii, aș recomanda să te uiți la răspunsul lui @ EricZBeard.)
- person apple apple; 03.12.2019
În primul rând, așa cum subliniază @AndrewFinnell și @KenLiu, în SVN numele directoarelor în sine nu înseamnă nimic -- „trunk, ramuri și etichete” sunt pur și simplu o convenție comună care este folosită de majoritatea depozitelor. Nu toate proiectele folosesc toate directoarele (este destul de obișnuit să nu folosiți „etichete” deloc) și, de fapt, nimic nu vă împiedică să le numiți cum doriți, deși încălcarea convențiilor este adesea confuză.
Voi descrie probabil cel mai comun scenariu de utilizare a ramurilor și etichetelor și voi da un exemplu de scenariu despre modul în care sunt utilizate.
Trunk: zona principală de dezvoltare. Aici se află următoarea versiune majoră a codului și, în general, are toate cele mai noi caracteristici.
Sucursale: de fiecare dată când lansați o versiune majoră, se creează o ramură. Acest lucru vă permite să remediați erori și să faceți o nouă lansare fără a fi nevoie să lansați cele mai noi - posibil neterminate sau netestate - caracteristici.
Etichete: de fiecare dată când lansați o versiune (lansare finală, candidate pentru lansare (RC) și beta), creați o etichetă pentru aceasta. Acest lucru vă oferă o copie punctuală a codului așa cum era în acea stare, permițându-vă să reveniți și să reproduceți orice erori, dacă este necesar, într-o versiune anterioară sau să relansați o versiune anterioară exact așa cum a fost. Ramurile și etichetele din SVN sunt ușoare - pe server, nu face o copie completă a fișierelor, doar un marker care spune „aceste fișiere au fost copiate la această revizuire” care ocupă doar câțiva octeți. Având în vedere acest lucru, nu ar trebui să vă îngrijorați niciodată crearea unei etichete pentru orice cod lansat. După cum am spus mai devreme, etichetele sunt adesea omise și, în schimb, un jurnal de modificări sau alt document clarifică numărul de revizuire atunci când se face o lansare.
De exemplu, să presupunem că începeți un nou proiect. Începi să lucrezi în „trunk”, la ceea ce va fi lansat în cele din urmă ca versiunea 1.0.
Odată ce 1.0.0 este terminat, ramificați trunchiul într-o nouă ramură „1.0” și creați o etichetă „1.0.0”. Acum lucrați la ceea ce va fi în cele din urmă 1.1 continuă în portbagaj.
Întâlniți câteva erori în cod și le remediați în trunk, apoi îmbinați remedierea în ramura 1.0. Puteți, de asemenea, să faceți opusul și să remediați erorile din ramura 1.0 și apoi să le îmbinați înapoi în trunchi, dar de obicei proiectele se limitează la fuziunea într-un singur sens doar pentru a reduce șansa de a pierde ceva. Uneori, un bug poate fi remediat doar în 1.0, deoarece este învechit în 1.1. Nu contează cu adevărat: vrei doar să te asiguri că nu lansezi 1.1 cu aceleași erori care au fost remediate în 1.0.
Odată ce găsiți suficiente erori (sau poate o eroare critică), vă decideți să faceți o versiune 1.0.1. Deci faci o etichetă „1.0.1” din ramura 1.0 și eliberezi codul. În acest moment, trunchiul va conține ceea ce va fi 1.1, iar ramura „1.0” conține codul 1.0.1. Data viitoare când lansați o actualizare la 1.0, aceasta va fi 1.0.2.
În cele din urmă, ești aproape gata să lansezi 1.1, dar mai întâi vrei să faci o versiune beta. În acest caz, probabil că veți face o ramură „1.1” și o etichetă „1.1beta1”. Acum, lucrul la ceea ce va fi 1.2 (sau 2.0 poate) continuă în trunk, dar lucrul la 1.1 continuă în ramura „1.1”.
Odată ce lansați 1.1 final, faceți o etichetă „1.1” din ramura „1.1”.
De asemenea, puteți continua să mențineți 1.0 dacă doriți, portarea remedierii erorilor între toate cele trei ramuri (1.0, 1.1 și trunk). Cea mai importantă concluzie este că pentru fiecare versiune principală a software-ului pe care o întrețineți, aveți o ramură care conține cea mai recentă versiune de cod pentru acea versiune.
O altă utilizare a ramurilor este pentru caracteristici. Aici ramificați trunchiul (sau una dintre ramurile de lansare) și lucrați la o nouă caracteristică în mod izolat. Odată ce caracteristica este finalizată, o îmbinați din nou și eliminați ramura.
Ideea este atunci când lucrezi la ceva perturbator (care ar împiedica sau interfera cu alți oameni să-și facă munca), ceva experimental (care poate nici măcar să nu ajungă) sau, eventual, doar ceva care durează mult timp. (și vă este teamă dacă ține o versiune 1.2 când sunteți gata să ramificați 1.2 din trunchi), o puteți face izolat în ramură. În general, îl țineți actualizat cu trunchiul, îmbinând modificările în acesta tot timpul, ceea ce face mai ușor de reintegrat (imbinarea înapoi în trunchi) când ați terminat.
De asemenea, rețineți că schema de versiuni pe care am folosit-o aici este doar una dintre multe. Unele echipe ar face lansări de remediere/întreținere a erorilor ca 1.1, 1.2 etc. și modificări majore ca 1.x, 2.x etc. Utilizarea aici este aceeași, dar puteți numi ramura „1” sau „1”. .x” în loc de „1.0” sau „1.0.x”. (În afară de aceasta, versiune semantică este un ghid bun despre cum să faci numere de versiune).
În plus față de ceea ce a spus Nick, puteți afla mai multe la Linii în flux: modele de ramificare pentru dezvoltarea software paralelă
În această figură main este trunchiul, rel1-maint este o ramură și 1.0 este o etichetă.
În general (vedere agnostică a instrumentului), o ramură este mecanismul utilizat pentru dezvoltarea paralelă. Un SCM poate avea de la 0 la n ramuri. Subversion are 0.
Trunk este o ramură principală recomandat de Subversion, dar nu sunteți forțat în niciun caz să îl creați. L-ați putea numi „principal” sau „lansări”, sau nu aveți deloc unul!
Sucursala reprezintă un efort de dezvoltare. Nu ar trebui să fie numit niciodată după o resursă (cum ar fi „vonc_branch”), ci după:
#P5#
O etichetă este finală. Conținutul său nu ar trebui să se schimbe niciodată. NU. Vreodată. Ai uitat un rând din nota de lansare? Creați o nouă etichetă. Învechit sau eliminați-l pe cel vechi.
Acum, am citit multe despre „contopirea înapoi cutare și cutare în așa și așa ramuri, apoi în sfârșit în ramura trunchiului”. Acesta se numește flux de lucru de îmbinare și nu este nimic obligatoriu aici. Nu pentru că aveți o ramură de trunchi trebuie să îmbinați înapoi orice.
Prin convenție, ramura trunk poate reprezenta starea curentă a dezvoltării dvs., dar aceasta este pentru un proiect secvenţial simplu, adică un proiect care are:
Pentru că cu unul (sau toate) dintre aceste scenarii, obțineți patru „trunchiuri”, patru „evoluții curente”, și nu tot ceea ce faceți în acele dezvoltări paralele va trebui neapărat să fie fuzionat înapoi în „trunchi”.
În SVN, o etichetă și o ramură sunt într-adevăr similare.
Etichetă = o porțiune definită în timp, folosită de obicei pentru lansări
Branch = de asemenea, o porțiune definită în timp pe care dezvoltarea poate continua, de obicei folosită pentru versiunile majore, cum ar fi 1.0, 1.5, 2.0 etc., apoi, atunci când eliberați, etichetați ramura. Acest lucru vă permite să continuați să susțineți o lansare de producție, în timp ce mergeți mai departe cu modificări rupturi în portbagaj
Trunk = spațiu de lucru de dezvoltare, aici ar trebui să aibă loc toată dezvoltarea și apoi modificările fuzionate din lansările de ramuri.
Nu au nicio semnificație formală. Un folder este un folder către SVN. Sunt o modalitate general acceptată de a vă organiza proiectul.
Portbagajul este locul în care vă păstrați linia principală de dezvoltare. Dosarul de ramuri este locul în care ați putea crea, ei bine, ramuri, care sunt greu de explicat într-o postare scurtă.
O ramură este o copie a unui subset al proiectului dumneavoastră la care lucrați separat de trunchi. Poate că este pentru experimente care s-ar putea să nu ajungă nicăieri, sau poate este pentru următoarea ediție, pe care o vei îmbina mai târziu în portbagaj când va deveni stabil.
Și folderul etichete este pentru crearea de copii etichetate ale depozitului dvs., de obicei la punctele de control al lansării.
Dar, așa cum am spus, pentru SVN, un folder este un folder. branch, trunk și eticheta sunt doar o convenție.
Folosesc cu generozitate cuvântul „copiere”. SVN nu face de fapt copii complete ale lucrurilor din depozit.
Trunk-ul este linia de dezvoltare care deține cel mai recent cod sursă și funcții. Ar trebui să aibă cele mai recente remedieri de erori, precum și cele mai recente caracteristici adăugate proiectului.
ramurile sunt de obicei folosite pentru a face ceva departe de trunchi (sau altă linie de dezvoltare) care altfel ar rupe construcția. Caracteristicile noi sunt adesea construite într-o ramură și apoi fuzionate înapoi în portbagaj. Filialele conțin adesea cod care nu este neapărat aprobat pentru linia de dezvoltare de la care s-a ramificat. De exemplu, un programator ar putea încerca o optimizare pe ceva dintr-o ramură și să fuzioneze înapoi în linia de dezvoltare numai după ce optimizarea este satisfăcătoare.
Etichetele sunt instantanee ale depozitului la un anumit moment. Nu ar trebui să apară nicio dezvoltare asupra acestora. Ele sunt cel mai adesea folosite pentru a prelua o copie a ceea ce a fost eliberat unui client, astfel încât să puteți avea acces cu ușurință la ceea ce folosește un client.
Iată un link către un ghid foarte bun pentru depozite:
De asemenea, articolele din Wikipedia merită citite.
Acum asta e treaba cu dezvoltarea de software, nu există cunoștințe consistente despre nimic, toată lumea pare să o aibă în felul lui, dar asta pentru că oricum este o disciplină relativ tânără.
Iată modul meu simplu,
trunk - directorul trunk conține cel mai actual, aprobat și îmbinat corpul de lucrări. Contrar a ceea ce au mărturisit mulți, portbagajul meu este doar pentru lucrări curate, îngrijite, aprobate, și nu o zonă de dezvoltare, ci mai degrabă o zonă de degajare.
La un moment dat, când portbagajul pare să fie gata de eliberare, atunci este etichetat și eliberat.
filiale - directorul de ramuri conține experimente și lucrări în desfășurare. Munca sub o ramură rămâne acolo până când este aprobată îmbinarea în portbagaj. Pentru mine, aceasta este zona în care se face toată munca.
De exemplu: pot avea o ramură iterație-5 pentru a cincea rundă de dezvoltare a produsului, poate o ramură prototip-9 pentru a noua rundă de experimentare și așadar pe.
etichete - directorul de etichete conține instantanee ale ramurilor aprobate și ale lansărilor trunchiului. Ori de câte ori o ramură este aprobată să fuzioneze în trunchi sau se face o eliberare a trunchiului, se face un instantaneu al ramurului aprobat sau al eliberării trunchiului sub etichete.
Presupun că, cu etichete, pot sări înainte și înapoi prin timp la punctele de interes destul de ușor.
Am găsit acest tutorial grozav despre SVN când căutam site-ul autor al OpenCV 2 Computer Vision Application Programming Cookbook și m-am gândit că ar trebui să o împărtășesc.
Are un tutorial despre cum să folosești SVN și ce înseamnă expresiile „trunk”, „tag” și „branch”.
Citat direct din tutorialul său:
Versiunea actuală a proiectului dvs. de software, la care echipa dvs. lucrează în prezent, se află de obicei sub un director numit trunk. Pe măsură ce proiectul evoluează, dezvoltatorul actualizează versiunea respectivă, remediază erori, adaugă funcții noi) și trimite modificările în acel director.
În orice moment dat, este posibil să doriți să înghețați o versiune și să faceți un instantaneu al software-ului așa cum este în această etapă a dezvoltării. Aceasta corespunde, în general, versiunilor oficiale ale software-ului dumneavoastră, de exemplu, cele pe care le veți livra clienților dumneavoastră. Aceste instantanee sunt situate sub directorul etichete al proiectului dvs.
În cele din urmă, este adesea util să creați, la un moment dat, o nouă linie de dezvoltare pentru software-ul dvs. Acest lucru se întâmplă, de exemplu, atunci când doriți să testați o implementare alternativă în care trebuie să vă modificați software-ul, dar nu doriți să transmiteți aceste modificări proiectului principal până când decideți dacă adoptați noua soluție. Echipa principală poate continua apoi să lucreze la proiect, în timp ce alți dezvoltatori lucrează la prototip. Veți pune aceste noi linii de dezvoltare ale proiectului într-un director numit ramuri.
Directorul trunk este directorul cu care probabil ești cel mai familiarizat, deoarece este folosit pentru a păstra cele mai recente modificări. Baza de cod principală ar trebui să fie în portbagaj.
Directorul de ramuri este pentru a vă păstra ramurile, oricare ar fi acestea.
Directorul de etichete este practic pentru etichetarea unui anumit set de fișiere. Faceți acest lucru pentru lucruri precum versiuni, în care doriți ca „1.0” să fie aceste fișiere la aceste revizuiri și „1.1” să fie aceste fișiere la aceste revizuiri. De obicei, nu modificați etichetele odată ce sunt create. Pentru mai multe informații despre etichete, consultați Capitolul 4. Ramificare și Fuzionarea (în Version Control with Subversion).
Unul dintre motivele pentru care toată lumea are o definiție ușor diferită este că Subversion implementează suport zero pentru ramuri și etichete. Subversion spune practic: Ne-am uitat la ramuri și etichete cu funcții complete în alte sisteme și nu le-am găsit utile, așa că nu am implementat nimic. Doar faceți o copie într-un director nou cu un nume convenție în schimb. Atunci, desigur, fiecare este liber să aibă convenții ușor diferite. Pentru a înțelege diferența dintre o etichetă real și o simplă convenție de copiere + denumire, consultați intrarea Wikipedia Etichete și ramuri de subversiune.
Tag = o porțiune definită în timp, folosită de obicei pentru lansări
Cred că asta este ceea ce se înțelege de obicei prin „etichetă”. Dar în Subversion:
Nu au nicio semnificație formală. Un folder este un folder către SVN.
ceea ce mi se pare destul de confuz: un sistem de control al reviziilor care nu știe nimic despre ramuri sau etichete. Din punct de vedere al implementării, cred că modul Subversion de a crea „copii” este foarte inteligent, dar dacă trebuie să știu despre el este ceea ce aș numi un abstracție leaky.
Sau poate că am folosit de prea mult timp CVS.
Cred că o parte din confuzie provine din diferența dintre conceptul de etichetă și implementarea în SVN. Pentru SVN, o etichetă este o ramură care este o copie. Modificarea etichetelor este considerată greșită și, de fapt, instrumente precum TortoiseSVN vă vor avertiza dacă încercați să modificați ceva cu ../tags/.. în cale.
Nu sunt foarte sigur ce este „etichetă”, dar ramura este un concept de control al sursei destul de comun.
Practic, o ramură este o modalitate de a lucra la modificările aduse codului fără a afecta trunchiul. Să presupunem că doriți să adăugați o nouă caracteristică destul de complicată. Doriți să puteți verifica modificările pe măsură ce le faceți, dar nu doriți ca acestea să afecteze trunchiul până când nu terminați cu funcția.
Mai întâi ai crea o ramură. Aceasta este practic o copie a trunchiului din momentul în care ați făcut ramura. Atunci ți-ai face toată treaba în ramură. Orice modificare făcută în ramură nu afectează trunchiul, astfel încât trunchiul este încă utilizabil, permițând altora să continue să lucreze acolo (cum ar fi remedierea erorilor sau mici îmbunătățiri). Odată ce funcția dvs. este finalizată, veți integra ramura înapoi în trunchi. Acest lucru ar muta toate modificările dvs. de la ramură la trunchi.
Există o serie de modele pe care oamenii le folosesc pentru ramuri. Dacă aveți un produs cu mai multe versiuni majore acceptate simultan, de obicei fiecare versiune ar fi o ramură. Acolo unde lucrez avem o sucursală QA și o sucursală Productie. Înainte de a lansa codul nostru pentru QA, integrăm modificările în ramura QA, apoi implementăm de acolo. Când lansăm în producție, integrăm din filiala QA în filiala Production, așa că știm că codul care rulează în producție este identic cu ceea ce a testat QA.
Iată înscrierea Wikipedia despre ramuri, deoarece probabil explică lucrurile mai bine decât pot eu . :)
Bag: după finalizarea fiecărui sprint în agil, ieșim cu un produs care poate fi livrat parțial. Aceste versiuni sunt păstrate în portbagaj.
Sucursale: toate codurile de dezvoltare paralelă pentru fiecare sprint în curs sunt păstrate în ramuri.
Etichete: de fiecare dată când lansăm o versiune beta a unui produs care poate fi livrat parțial, creăm o etichetă pentru acesta. Acest lucru ne oferă codul care era disponibil la acel moment, permițându-ne să revenim la acea stare dacă este necesar la un moment dat în timpul dezvoltării.
Pentru persoanele familiarizate cu GIT, master în GIT este echivalent cu trunk în SVN.
Ramura și eticheta au aceeași terminologie atât în GIT, cât și în SVN.
