10 lucruri pe care le urăsc despre Git; Blogurile Steve Bennett
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.
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
- Găsiți baza de îmbinare între sucursală și master: „git merge-bază master sucursala dvs.”
- 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ă:
- git rebase –onto HEAD
1 CAP
1 ’
1 ’).