Acesta este un flux de lucru git foarte simplu. Acesta (si variantele) este utilizat de multi oameni. M-am stabilit dupa el dupa ce l-am folosit foarte eficient la Athena. GitHub face ceva similar; Zach Holman a mentionat-o in aceasta discutie.

Esentialul

  1. master trebuie sa fie intotdeauna implementabil.
  2. toate modificarile facute prin ramuri de caracteristici (pull-request + merge)
  3. rebase pentru a evita / rezolva conflictele; fuzioneaza pentru a stapani

Sau, dupa cum a spus succint Zach Holman:

Fluxul de lucru

# totul este fericit si actualizat in master git checkout master git pull origin master # hai sa ne ramificam pentru a face modificari git checkout -b functia mea noua # continuati, faceti modificari acum. Fisierul $ EDITOR # comite modificarile dvs. (incrementale, atomice) git add -p git commit -m “modificarile mele” # tineti la curent cu alte modificari, la ramura caracteristica sau la master. # rebasing mentine codul nostru functional, fuzionand usor si istoricul curat. git fetch origin git rebase origin / my-new-feature git rebase origin / master # optional: impingeti ramura pentru discutie (pull-request) # ati putea face acest lucru de multe ori pe masura ce va dezvoltati. git push origin my-new-feature # optional: simtiti-va liber sa reinstalati in ramura functionala dupa bunul plac. # ok sa refaceti dupa ce ati impins daca echipa dvs. se poate descurca! git rebase -i origine / master # merge la terminarea dezvoltarii. # –no-ff pastreaza istoricul caracteristicilor si revine usor cu caracteristicile complete # comitetele de imbinare nu trebuie sa includa modificari; rebasing reconcilie issues # github se ocupa de acest lucru intr-un pull-request merge git checkout master git pull origine master git merge –no-ff my-new-feature # optional: etichetati lucruri importante, cum ar fi release-urile git 1.0.0- RC1

config util

# autosetup rebase astfel incat sa atraga rebase in mod implicit git config –global branch.autosetuprebase intotdeauna # daca aveti deja ramuri (facute inainte de „autosetuprebase intotdeauna”) git config branch. <branchname> .rebase true

Ce sa faci si ce sa nu faci

Nici un DO sau NU este sacru. Evident, veti intalni exceptii si va veti dezvolta propriul mod de a face lucrurile. Cu toate acestea, acestea sunt recomandarile pe care le-am considerat utile.

DO-uri

  • DO pastra maestru in stare de functionare.
  • DO rebase crengi caracteristica.
    • DO trage in (rebase pe partea de sus a) se modifica
  • Lansati eticheta DO
  • DO sucursale caracteristica de impingere pentru discutii
  • DO invata sa rebase

NU

Link-uri

  • https://github.com/blog/1124-how-we-use-pull-requests-to-build-github

FAQ

Git merge nu – ff genereaza bule de imbinare?

Da. Bulele de imbinare nu sunt inerent rele. Acestea va permit sa reveniti la toate caracteristicile la un moment dat. Devin confuze si enervante de tratat daca incruciseaza (comite intercalare), asa ca nu faceti asta.

Ce vrei sa spui prin schimbari „incrementale, atomice”?

http://en.wikipedia.org/wiki/Atomic_commit#Atomic_Commit_Convention

Multumesc wikipedia, nu as fi putut sa o pun eu mai bine.

De ce nu gitflow sau un alt flux de lucru complex?

Fii invitatul meu. Am folosit gitflow si alte modele similare. Dupa ce am lucrat in diverse echipe, tocmai asta am ajuns sa folosesc. Dar data viitoare cand trebuie sa intrebati pe cineva daca este in regula sa impingeti sau sa trageti de aceasta ramura sau de aceea, amintiti-va de fata mea.

Dar, este la scara web?

Prietenii sustin ca sunt necesare modele mai complexe pentru scalarea echipelor mari, mentinerea versiunilor vechi, controlul fluxului de informatii etc. Foarte bine se poate intampla ca utilizarea mai multor linii principale (de exemplu, dezvoltare, stabila, versiune, v2, testata etc.) constrangerile organizatiei. Asta trebuie sa decideti tu, nu eu (daca nu lucram impreuna – oh, acolo!).

Dar intotdeauna trebuie sa va intrebati „nu ar trebui sa folosesc etichete pentru asta”? De exemplu, urmarirea lansarilor pe o ramura este un pic prostie. Un commit de lansare poate fi etichetat. Puteti sa verificati o eticheta, la fel ca orice sucursala sau orice comitere, si sa faceti tot ce trebuie sa faceti.

Cred ca aceasta relatie are:

Asadar, poate ca ai nevoie de cinci minute pentru a-ti invata echipa cum sa foloseasca checkout-ul si eticheta ar putea economisi mai mult de 15% la asigurarea auto.

Note GitHub

Nu furca. Impingeti ramurile de caracteristici la repo principal.

Uneori vad oameni care bifeaza depozite pentru a emite cereri pull. Da, poate fi necesar sa faceti acest lucru atunci cand contribuiti la proiecte open source la care nu contribuiti in mod regulat. Dar, daca sunteti un colaborator sau lucrati in aceeasi organizatie, obtineti drepturi push pe repo si impingeti toate ramurile de caracteristici catre acesta. Emiteti cereri de extragere de la o sucursala la alta in cadrul aceleiasi repo.

Ar trebui sa fuzionez Solicitari Pull pe site sau linie de comanda?

Depinde de tine. Github face git merge –no-ff, astfel incat mesajul de confirmare sa indice numarul cererii de extragere. Acestea sunt informatii utile, nu aruncati doar istoria de dragul ei. Nu stii niciodata ce va fi util sa te uiti in viitor.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR