Folosesc un git pentru proiectul meu, lucrez singur.
Iar acum sunt pregătit pentru lansarea primei versiuni, urmând sfatul despre acest articol pe hub și aici este descris că este necesar să creați o ramură de lansare și cum va fi adusă la lansare, apoi să o îmbinați în master și în dezvoltare și apoi să o ștergeți.
Dar de ce ar trebui să creez o ramură de eliberare dacă am totul gata în ramura de dezvoltare? Înțeleg că trebuie să o îmbin în expertul imediat și să o etichetez și să continui continuarea proiectului în deflope.
Dar am local doar o ramură de dezvoltare și eliminat există un dezvoltator și un maestru.
Întrebarea este că este corect să faci o comitet pe ramura locală a dezvoltării. puneți-o pe o etichetă, îmbinați-o într-un dezvoltator de la distanță și ați șters deja dezvoltatorul pentru a ucide comandantul de la distanță.
Nu sunt sigur că acest concept este corect și, în al doilea rând, nu sunt sigur ce puteți face în ramificațiile de la distanță.
Indicați cum să faceți acest lucru în mod corect?
Mai întâi un pic de teorie pentru a justifica recomandări practice. Sper că nu veți avea timp să vă plictisiți.
Și pentru echipe
- puțini, până la aproximativ 10 persoane;
- să lucrați pe agile și să distrugeți sarcinile astfel încât să se facă într-o zi sau două;
- utilizați cea mai recentă versiune a produsului și nu ar trebui să trageți versiunile vechi;
fluxul de git nu este pur și simplu necesar. Creează mai multe probleme decât rezolvă.
Dar de ce ar trebui să creez o ramură de eliberare dacă am totul gata în ramura de dezvoltare
Așa este! Tu și dezvoltatorul nu e nevoie.
Pentru echipele mici și dezvoltarea solo, modelele "ușoare" ale organizării fluxului de lucru sunt mai potrivite. Cea mai populară se numește GitHub Flow, se distinge prin câteva detalii și o profunzime mai mare a elaborării fluxului GitLab și a debitului Simple Git Flow (Atlassian).
Esența tuturor modelelor simple de flux de lucru
- Există un singur șef stabil (permanent, cu durată lungă de viață).
- Orice caracteristică sau remediere a erorilor se face într-o ramură separată, care se înființează de la comandant.
- Odată ce caracteristica sau bugfixul este gata, a trecut examinarea și testarea, ramura corespunzătoare este măsurată în maestru. Apoi ramura trebuie îndepărtată, astfel încât să nu se acumuleze gunoi.
În plus față de simplitatea evidentă, avantajul este că codul nu este scris "pe masă" și nu rămâne în ramurile de eliberare, dar este eliberat cât mai repede posibil. Cu cât este mai mică calea de la idee la producție, cu atât este mai bine pentru cauză. Clienții (utilizatorii) obțin mai rapid funcții noi și obțineți feedback mai rapid din partea clienților și bani pentru aceste caracteristici.
Cum se creează și se numesc ramuri
Este acceptat să porniți numele ramurii de caracteristici de la numărul de sarcină din instrumentul de urmărire a sarcinilor.
Ești undeva pe lista sarcinilor? Începeți, dacă nu, și iată de ce:
- Să nu le ții minte, tk. este nesigur și mănâncă resursele creierului
- Astfel încât puteți evalua, planifica, selecta prioritățile
- Pentru a stoca informații despre bug-uri și modalități de a le reproduce.
- Instruirea în echipă; probabil că nu veți lucra toată viața solo.
- În cazul în care proiectul este în open source, atunci cineva va veni și vă va primi un mesaj de sarcină sau un task-bugreport. Sau luați-vă sarcina și faceți-o, doar pentru nimic, pentru nimic. Nu poți face o sarcină care nu este descrisă, nu-i așa?
Formează sarcini mici, atomice, astfel încât munca în ramură să dureze 1-3 zile, nu mai mult. Acest lucru este important pentru munca solo și este extrem de important pentru munca în echipă.
De asemenea, este de dorit să inundați sucursalele locale la un server de la distanță, aceasta este o modalitate bună de a nu pierde codul când ați vărsat ceaiul într-un laptop, rm -rf /. incendiu, furt, meteorit.
Cum se măsoară ramurile
Există două modalități principale:
Ramura poate fi îngheată manual, local. Pe linia de comandă, acesta este cazul:
Dacă utilizați GitHub, GitLab, Bitbucket - puteți deschide un solicitant de tragere / îmbinare și apoi se blochează. În același timp, sucursalele de la distanță fac efectiv avantaje, atunci va trebui să trageți rezultatul măsurii (trageți git). Această metodă ajută la efectuarea inspecției codului în echipă și la diverse teste automate, dar dacă lucrați singur, cererile de îmbinare sunt aproape inutile.
caracteristici:
- Pentru a taia ramurile este necesar prin - nu-ff. să creați întotdeauna o comitere de îmbinare. Vă ajută să vedeți istoria, vă ajută să găsiți sucursala în care sa făcut comiterea. și denotă cu precizie locul în care această ramură a fost înghețată, poate fi anulată cu ajutorul lui git revert. Dragostea îmbinării de dragoste, ele vă vor fi de folos.
- Nu este nevoie să măsurați în comandant ceea ce nu este gata, nu este terminat etc. Ramura principală este sacră, trebuie să existe întotdeauna un cod de lucru în ea.
- Nu trebuie să măsurați ramura masterului în ramura de trăsături. Excepțiile trag codul de la eliberarea majoră la ramura cu durată lungă de viață, ramuri diferite pentru diferite medii de testare și alte situații care aproape nu apar în dezvoltarea solo a unui mic proiect.
Pentru a rula etichete pe un server la distanță, procedați astfel:
Este necesară opțiunea -follow-tags pentru a rula numai etichete adnotate și nu pentru cele ușoare, dacă le aveți brusc.
Nu marcați comitetele în arborele de caracteristici cu etichete de eliberare. Ei au înghețat, au testat rezultatul, au etichetat comitetul de îmbinare primit. Tot ce nu este în maestru. nu poate fi o eliberare.
Pentru a crea numere de versiune, utilizați versiuni semantice.
Eliberați cât mai des posibil
Deoarece ramura de bază este întotdeauna obligată să conțină codul de lucru și întotdeauna măsurați numai caracteristicile finale din acesta, fiecare îmbinare este de fapt o mică versiune. În același timp, re-compilați întotdeauna aplicația. Nu faptul că ar trebui eliberat imediat pentru toți utilizatorii - actualizările prea frecvente ale aplicației le pot deranja.
Încercați însă să asamblați un grup de testeri beta (începeți cu dvs.) pentru care veți elibera aplicația după fiecare ramură de merzha din comandant. În acest fel, veți accelera feedback-ul, iar cu cât ciclul OS va fi mai rapid, cu atât mai rapid va fi dezvoltat aplicația și abilitățile dvs. Aceasta este esența lui Agile.
Având în vedere cele de mai sus, propun un astfel de plan de acțiune.
- Îngheț (fuzionează) se dezvoltă în master.
- Așteptați eticheta Merge Commit.
- Îndepărtați ramura de dezvoltare și nu-l amintiți până la timp.
Și, în general, pentru răspunsul, vă mulțumesc! Am făcut-o. Numai am creat prima dată o ramură la nivel local din expertul de la distanță git checout -b master master # 47; master pe ramura pe care dezvoltatorul a făcut-o și a atârnat eticheta și a îmbinat-o pe acest dezvoltator local în asistentul local. Apoi a făcut o împingere, o etichetă și un maestru de ramură. Și, în cele din urmă, maestrul local a fost șters. Sunt deja puțin folosită când am o filială locală și din ea fac ramuri ale unei trăsături și maestrul și fetele sunt înlăturate. În expertul de la distanță, am îmbinat expertul local pentru salvare. - Aleksey Timoshenko 4 Oct 16 la 18:09
Nu sunt sigur că acest concept este corect
Poate fi atât corect, cât și nepotrivit pentru proiectul dvs. în același timp.
Nu sunt sigur ce puteți face pe ramurile la distanță.
Nu poți. Sincronizați filialele locale cu telecomenzi (preluați / trageți), îmbinați și sincronizați șters cu local (push). De fapt, chiar originea / sucursala master este de asemenea locală.
Indicați cum să faceți acest lucru în mod corect?
IT este un domeniu atât de interesant în care există multe răspunsuri corecte.
În special, pentru un proiect cu un dezvoltator, puteți gestiona o sucursală principală și etichete cu etichete.
git flow și alte metode funcționează bine numai dacă înțelegeți ce probleme rezolvă. În timp ce proiectul dvs. nu conține astfel de probleme, metodele însăși complică viața.
1 creați ramură rc
2 pentru a fi mort cu dispozitivul dvs. dev
3 ramură de turnare rc
Aceasta se face pentru a se asigura că în cazul unui kreshch a fost posibilă trecerea în condiții de siguranță la ramura stabilă anterioară, reparați o nouă ramură rc și eliberați-o din nou. Nu recomand să ștergeți foarte mult ramurile. În practică, este adesea necesar să se facă schimbări în alte ramuri. Dar dacă aveți ramuri din trecut și sunteți deja confuz în ele, atunci puteți să vă curățați și numai pe plan local (git branch -d <ветка>)
răspunsul dat 8 Oct 16 la 13:11
1) turnare înseamnă a face o tragere git pe drum. 2) Da, imaginați-vă situația în care dezvoltați modulul 1 din ramura r1
50 de angajamente. Un modul2 din r2 are, de asemenea, N comitete. Au murit. Ștergeți r1 (complet pe server și la origine push git origine: the_remote_branch). Și dintr-o dată ramificația sa rupt sau modulul 2 nu este necesară. Pe scurt, trebuie doar să restaurați rc1. Și începe căutarea unui comitet pe hash, iar comitetele sunt neclare câte. Dar acest lucru nu este limita, imaginați situația atunci când pomerzhilis a făcut apoi o revizuire în rc1 apoi în rc2 din nou pomerizhilis. În această situație, ramura este foarte dificil de căutat. - Konstantin Okhotnick 8 Oct 16 la 14:37
În cazul în care ați descris, puteți introduce 2 moduri:
- Mergeți pe calea fluxului de git, creând o ramură de eliberare și terminând imediat.
- Asigurați-vă că fuzionați cu masterul și cu [opțional] prin plasarea etichetei pe comandant.
Ambele metode vor da același rezultat, dar utilizând al doilea, trebuie să faceți mai puțin de lucru. Prin urmare, în opinia mea, merită să o utilizați.
Aici eliberarea unei ramuri se potrivește bine. De exemplu, echipa dvs. a realizat un anumit set de funcționalități, care este necesar pentru lansarea, de exemplu, versiunea 1.0. Toate acestea sunt în ramura de dezvoltare și nu aveți nicio încredere că codul este corect (nu a fost testat corect și managerul principal nu a studiat funcționalitatea). Ați putea posta rezultatul dezvoltării, dar ce să faceți cu dezvoltatorii în așteptare care nu pot să vărceteze noi funcționalități în dezvoltarea, deoarece există o gamă clar de caracteristici de lansare?
Pentru a vă asigura că dezvoltatorii nu sunt eliberați în mod inactiv într-o ramură în care nu puteți adăuga nicio funcție nouă, erorile și inexactitățile găsite ar trebui corectate. Atunci când toate erorile găsite sunt corectate și notele sunt luate în considerare - ramura de eliberare se închide, se îmbină cu comandantul și produsul este eliberat.
După cum puteți vedea, pentru dvs., ca și pentru un singur, ramura de eliberare nu este necesară. Prin urmare, treceți doar de acest pas dacă nu doriți să faceți o muncă suplimentară și rețineți că orice metodologie este un set de principii și reguli generale și aproape întotdeauna metodologia trebuie adaptată nevoilor unui anumit caz - dacă nu înțelegeți cum să utilizați ceva, atunci aproape sigur nu aveți nevoie de ea.
răspunsul dat 12 octombrie '16 la 5:41
Verificați dacă aveți o sucursală locală locală. Și pentru a face fuzionarea este necesar, desigur, la nivel local, și apoi să le descărcați în depozitul central.
În ceea ce privește necesitatea de a crea o ramură de lansare, atunci, probabil, totul depinde de modul în care dezvoltați proiectul și cum este organizat procesul. În secolul XXI, unde există Scrum, Integrare continuă și DevOps, desfășurarea proiectului poate avea loc printr-un singur buton și nu este necesar să îl modificați cu un fișier pentru fiecare lansare într-o ramură separată.
Un alt lucru, eliberarea ramurii permanente. Poate fi util pentru implementarea aceleiași derulări cu un singur buton. Există mai multe modalități diferite de a implementa acest comportament, iar unul dintre ele este să atârna cârligul de pe ramura de eliberare a presei. pe care noul cod va fi implementat pe serverul de operare industrială (este producția).
Apoi scrieți și testați codul într-o singură ramură, numiți-l dev. și când credeți că codul funcționează corect, vărsați modificările în lansare. iar serverul dvs. de construire colectează pachetul de instalare sau implementează codul de pe serverul web.
În acest caz, desigur, puneți etichetele și plasați-le unde doriți. Ramura dev este bine.
răspuns dat dat 11 Oct 16 la 4:45 am
Dar de ce ar trebui să creez o ramură de eliberare dacă am totul gata în ramura de dezvoltare?
Toată farmecul ramurilor nu este numai că obțineți copia dvs. de proiect, ci și că angajamentele dvs. vor fi combinate în mod logic:
Ie veți vedea apoi că aceste cinci angajamente au fost făcute ca parte a implementării acestei caracteristici
Nu ascultă pe nimeni, pentru că esti singurul dezvoltator, atunci nu poti respecta toate aceste reguli ale gitflow. Aflați cum funcționează corect de la început!
Folosind modelul cu flux git și lucrați cu git curat. da, veți executa comenzi suplimentare care vă vor încetini. Dar aceasta nu este problema acestui model, ci problema ta, pentru că nu folosiți utilitățile necesare ;-) De exemplu, folosesc gitflow-avh. configurat .gitconf
și a adăugat aliasuri la .bashrc
Nu știu despre tine, dar chiar de la început, când l-am întâlnit pe Git. Am fost confundat cu înțelegerea faptului că există sucursale de maestru. producție. se dezvolta. De aceea am decis pentru mine. IMHO:
- Sucursala, pe care o depunem pe serverul de luptă - producție
- Filiala în care se realizează dezvoltarea (atunci unde vă măsurați caracteristicile) - se dezvoltă
Dar am local doar o ramură de dezvoltare și eliminat există un dezvoltator și un maestru.
Răspunzând la întrebarea dvs. cum să faceți acest lucru în mod corect, vă voi atrage atenția asupra faptului că munca dvs. se desfășoară întotdeauna pe plan local, iar cu un depozit la distanță efectuați doar sincronizarea. prin urmare
- Faceți măsura dezvoltatorului dvs. local în comandantul local
- Faceți apăsarea expertului local la distanță
Ei bine, atunci voi sprijini acest răspuns detaliat, cu excepția unor momente:
Există un singur master de ramură stabil.
Nu poate fi numit stabil până nu îl testați. În timpul testării, puteți detecta o eroare în cazul în care comiteți comiterea suplimentară a comandantului pentru remedierea acesteia. În consecință, la comitetul anterior, sucursala dvs. nu este stabilă.
Din acest motiv, ramura de eliberare a fost inventată. În care puteți face cel puțin câteva iterații de testare, după care eliberați eliberarea și faceți măsura sucursalei în master / producție și dezvoltați.
Lasă-l să nu spună, dar în orice caz ar trebui să ai următoarele ramuri:
- O ramură de producție este o ramură în care orice comitet este garantat să fie pregătit pentru o deploi.
- să dezvoltați o ramură este o ramură în care vă îmbinați funcțiile
- raza de remediere rapidă - această ramură (nu pentru a face cireș-pick de la prod la virgin) în care faceți remedii
- ramura de eliberare - pentru crearea de eliberare liniștită
Deci, chiar dacă sunteți un programator cu un singur jucător, vă recomandăm să urmați modelul flow-flow pentru a putea funcționa corect
Articole similare
Trimiteți-le prietenilor: