Confidențialitate și module cookie

Acest site folosește cookie-uri. Continuând, sunteți de acord cu utilizarea lor. Aflați mai multe, inclusiv cum să controlați cookie-urile.

lucruri

Git este sistemul de control al versiunii codului sursă care devine rapid standardul pentru proiectele open source. Are un model puternic distribuit care permite utilizatorilor avansați să facă lucruri complicate cu sucursale și să rescrie istoricul. Ce păcat că este atât de greu de învățat, că are o interfață de linie de comandă atât de neplăcută și își tratează utilizatorii cu atât de dispreț.

1. Model informațional complex

Modelul informațional este complicat - și trebuie să știți totul. Ca punct de referință, luați în considerare Subversion: aveți fișiere, un director de lucru, un depozit, versiuni, ramuri și etichete. Este cam tot ce trebuie să știi. De fapt, ramurile sunt etichete și fișiere despre care știți deja, așa că trebuie să aflați cu adevărat trei lucruri noi. Versiunile sunt liniare, cu ciudată îmbinare. Acum Git: aveți fișiere, un arbore de lucru, un index, un depozit local, un depozit la distanță, telecomenzi (indicatori către depozite la distanță), comitere, arborescențe (indicatori pentru comitere), ramuri, un stash ... și trebuie să știți toate din ea.

2. Sintaxa nebună a liniei de comandă

Sintaxa liniei de comandă este complet arbitrară și inconsistentă. Unele „comenzi rapide” sunt combinate cu comenzi de nivel superior: „git pull” este exact echivalent cu „git fetch” urmat de „git merge”. Dar comanda rapidă pentru „git branch” combinată cu „git checkout”? „Git checkout -b”. Specificarea numelor de fișiere modifică complet semantica anumitor comenzi („git commit” ignoră modificările locale, neetajate în foo.txt; „git commit foo.txt” nu). Diferitele opțiuni de „resetare git” fac lucruri complet diferite.

Cel mai spectaculos exemplu în acest sens este comanda „git am”, care, din câte îmi dau seama, este ceva pe care Linus l-a spart și forțat în baza de cod principală pentru a rezolva o problemă pe care o avea într-o noapte. Acesta combină citirea e-mailurilor cu aplicarea patch-urilor și, astfel, folosește o sintaxă de patch-uri diferită (în mod specific, una cu anteturi de e-mail în partea de sus).

3. Documentație mizerabilă

Paginile de om sunt un „atotputernic” atotputernic. Acestea descriu comenzile din perspectiva unui informatician, nu a unui utilizator. Caz elocvent:

git-push - Actualizați referințele la distanță împreună cu obiectele asociate

Iată o descriere pentru oameni: git-push - Încărcați modificările din depozitul dvs. local într-un depozit la distanță

Actualizați, un alt exemplu: (mulțumesc cgd)

git-rebase - Portul local de redirecționare se angajează la capul din amonte actualizat

Traducere: git-rebase - Regenerați secvențial o serie de confirmări, astfel încât să poată fi aplicate direct pe nodul principal

4. Extinderea modelului informațional

Vă amintiți modelul de informații complicat din pasul 1? Continuă să crească, ca un cancer. Continuați să utilizați Git, iar mai multe concepte vor ieși din cer din când în când: referințe, etichete, reflog, comitere rapidă, starea capului detașat (!), Ramuri la distanță, urmărire, spații de nume

5. Abstracție cu scurgeri

  1. Găsiți baza de îmbinare între sucursală și master: „git merge-bază master sucursala dvs.”
  2. Presupunând că v-ați angajat deja modificările, v-ați modificat validarea în baza de îmbinare, apoi creați o nouă ramură:
  3. git rebase –onto HEAD

1 CAP

  • git checkout -b-new-new-branch
  • Verificați ramura de ruggedizare și eliminați commit-ul pe care tocmai l-ați rebasat: ‘git reset – hard HEAD

    1 ’

  • Îmbinați noua filială din nou în rezistență: „git merge my-new-branch”
  • Checkout master („git checkout master”), îmbinați noua ramură în („git merge my-new-branch”) și verificați dacă funcționează atunci când fuzionați, apoi eliminați îmbinarea („git reset – HEAD hard

    1 ’).

  • Împingeți noua filială („git push origin my-new-branch”) și înregistrați o cerere de extragere.

    • 6. Puterea întreținătorului, pe cheltuiala contribuitorului

    Cea mai mare parte a puterii lui Git se adresează în mod clar întreținătorilor bazelor de cod: persoanele care trebuie să îmbine contribuțiile dintr-un număr mare de surse diferite sau care trebuie să asigure o serie de eforturi de dezvoltare paralele duc la o versiune unică, coerentă și stabilă. Asta e bine. Dar majoritatea utilizatorilor Git nu se află în această situație: scriu pur și simplu cod, de multe ori pe o singură sucursală timp de luni la rând. Git este un espressor cu 4 mânere, cu două cazane - când tot ce au nevoie este instantaneu.

    Interesant, nu cred că acest compromis este inerent designului Git. Este pur și simplu rezultatul ignorării nevoilor utilizatorilor normali și confuziei arhitecturii cu interfața. „Git este bun” este adevărat dacă vorbim despre arhitectură - dar fals despre interfața cu utilizatorul. Cineva ar putea scrie, cu siguranță, o interfață îmbunătățită (easygit este un început) care ascunde complexitatea inutilă, cum ar fi indexul și depozitul local.

    7. Controlul versiunii nesigure

    Promisiunea fundamentală a oricărui sistem de control al versiunilor este următoarea: „Odată ce ați introdus prețiosul cod sursă aici, este sigur. Puteți face orice modificare doriți și o puteți obține oricând ”. Git încalcă această promisiune. Mai multe moduri în care un comitator poate distruge irevocabil conținutul unui depozit:

    1. git add. /…/Git push -f origin master
    2. git push origine + master
    3. git rebase -i/git push

    8. Sarcina întreținerii VCS a fost împinsă către contribuabili

    În proiectul tradițional open source, o singură persoană trebuia să se ocupe de complexitatea ramurilor și fuzionează: întreținătorul. Toți ceilalți au trebuit doar să actualizeze, să comită, să actualizeze, să comită, să actualizeze, să comită ... Git renunță la toată povara înțelegerii controlului complex al versiunilor - facilitând în același timp munca de întreținere. De ce ați face acest lucru noilor colaboratori - celor care nu au investit nimic în proiect și fiecare stimulent să ridice mâinile în sus și să plece?

    9. Istoria Git este o grămadă de minciuni

    Rezultatul principal al activității de dezvoltare ar trebui să fie codul sursă. Este o istorie bine întreținută un subprodus atât de important? Majoritatea argumentelor pentru rebase, în special, se bazează pe judecăți estetice despre „îmbinări dezordonate” din istorie sau „jurnale necitite”. Așadar, rebase vă încurajează să minți pentru a oferi altor dezvoltatori o istorie „curată”, „neclintită”. Sigur, soluția corectă este o ieșire mai bună a jurnalului care poate filtra aceste îmbinări nedorite.

    10. Sarcinile simple necesită atât de multe comenzi

    Dacă modificările dvs. implică crearea de fișiere noi, există un pas suplimentar dificil:

    1. Faceți câteva modificări
    2. svn add
    3. svn commit

    Pentru un proiect găzduit de Github, următoarele sunt în esență minimul minim:

    1. Faceți câteva modificări
    2. git add [nu trebuie confundat cu svn add]
    3. git commit
    4. git push
    5. Modificările dvs. sunt încă la jumătatea drumului. Acum conectați-vă la Github, găsiți-vă comiterea și lansați o „cerere de extragere”, astfel încât cineva din aval să o poată îmbina.

    În realitate, însă, administratorul acestui proiect găzduit de Github va prefera probabil ca modificările dvs. să se facă pe ramurile de caracteristici. Vă vor cere să lucrați astfel:

    1. git checkout master [pentru a vă asigura că fiecare caracteristică nouă începe de la linia de bază]
    2. git checkout -b newfeature
    3. Faceți câteva modificări
    4. git add [nu trebuie confundat cu svn add]
    5. git commit
    6. git push
    7. Acum conectați-vă la Github, treceți la noua ramură de caracteristici și lansați o „cerere de extragere”, astfel încât întreținătorul să o poată îmbina.

    Ca bonus suplimentar, iată o diagramă care ilustrează comenzile pe care un dezvoltator obișnuit pentru un proiect tradițional Subversion trebuie să le cunoască pentru a-și face treaba. Acesta este pâinea și untul VCS: verificarea unui depozit, comiterea modificărilor și obținerea actualizărilor.

    Comenzi și concepte „Pâine și unt” necesare pentru a lucra cu un depozit Subversion la distanță.

    Și acum iată cu ce trebuie să vă ocupați pentru un proiect tipic găzduit de Github:

    Comenzile și conceptele „pâine și unt” necesare pentru a lucra cu un proiect găzduit de Github.

    Dacă puterea Git este ramificarea și fuzionarea sofisticate, atunci slăbiciunea sa este complexitatea sarcinilor simple.

    Actualizare (3 august 2012)

    Această postare a lovit în mod evident un nerv și are mult trafic. M-am gândit că voi aborda unele dintre cele mai frecvente comentarii.

    Câteva incoerențe ale comenzilor bonus:

    Resetați/plătiți

    Pentru a reseta un fișier din directorul dvs. de lucru la starea de angajare:

    Pentru a reseta fiecare fișier din directorul dvs. de lucru la starea sa angajată:

    Telecomandă și ramuri

    Există o altă comandă în care separatorul este de la distanță: branchname, dar nu-mi amintesc acum.

    Opțiuni de comandă care sunt practic obligatorii

    Și, în sfârșit, o listă de comenzi pe care le-am observat, care sunt aproape inutile, fără opțiuni suplimentare.