Mi-a luat recent să învăț elementele de bază ale Git câtorva dintre angajații mei care tocmai învață programarea și încearcă să lucreze. După ce am căutat pe Internet articole pentru începători, am dat peste faptul că majoritatea dintre ele se referă la modul de utilizare a consolei Git sau la necesitatea și avantajul acesteia față de ceilalți. sisteme similare... Începătorul nu este de obicei prea bun la toate aceste lucruri. Cred că el, pentru început, nu are nevoie să știe toate acestea. La urma urmei, puteți utiliza Git pentru proiectele dvs. și puteți învăța toate deliciile sale în paralel cu programarea învățării. Dar,vă recomand cu tărie să luați acest articol ca articol introductiv și să aflați mai multe despre Git în viitor.
Curios cum funcționează acest instrument de control al versiunilor? Dacă lucrați în dezvoltare și nu înregistrați modificări la proiectul dvs., sunteți practic pierdut. Ce se întâmplă dacă se face o modificare pentru producție și se dă o eroare?
Dar de unde știe Geet ordinea de a face? Fiecare resursă tinde să necesite mai mult de un commit, toate modificările aduse fiecărei resurse trebuie să fie „grupate” la sfârșit pentru a face parte din proiect. Pentru a rezolva aceste două probleme, Git lucrează cu conceptul de ramuri. Astfel, puteți avea mai multe ramuri și în fiecare dintre ele puteți lucra la o funcție sau la un cod de corecție, de exemplu. Dar ce se întâmplă dacă aceleași linii s-au schimbat pe ambele ramuri? Simplu, există un conflict. Dar, de obicei, aceasta nu este o problemă prea greu de rezolvat și o vom analiza mai bine într-o viitoare postare aici, pe blog.
În general, sub articolul tăiat, cum se utilizeazăSmartGit și BitBucket îți poți îmbunătăți viața de dezvoltator începător.
M un mic plan al a ceea ce vom face:
- Crearea unui depozit pe Bitbucket.
- Clonarea depozitului (adăugarea acestuia la SmartGit).
- Efectuarea de angajamente.
- Anularea modificărilor.
- Crearea sucursalelor.
- Împingând ramuri pe depozit la distanță (încărcarea sucursalelor pe un server la distanță).
- Fuzionarea ramurilor.
Merge. Crearea unui depozit este o sarcină foarte simplă. Pentru aceasta vom folosi BitBucket, deci trebuie să aveți un cont acolo. După înregistrare, apăsați butonul „Creați” și completați câmpurile obligatorii. Să clonăm depozitul folosind SmartGit. Să luăm un link către depozitul nostru.
Revenind la subiect, atunci când „uniți” două ramuri, există posibilitatea acestei „îmbinări” menționate mai sus. Și creați undeva un folder de proiecte, deoarece îl vom folosi pe parcursul tutorialului. Primul dvs. commit va fi acum înregistrat!
Procedura de înregistrare este mai jos. Veți vedea că conținutul original al primei confirmări a fost restaurat. Folosind această comandă, va fi afișat un ecran care arată diferențele, așa cum se arată în intrarea de mai sus. Pentru aceasta trebuie să fuzionăm două ramuri. Observați că angajamentul „Al treilea angajament” apare deasupra „Al patrulea angajament”.
Acum lansați SmartGit, selectați „Proiect” - „Clonare” (sau Ctrl + Alt + O) și completați câmpurile obligatorii:
Sistemul vă va cere datele de conectare și parola Bitbucket:
În fereastra următoare există două opțiuni de clonare „Includeți submodule” și „Prindeți toate capetele și etichetele”. Git permite modulelor de aplicații separate să fie stocate în diferite depozite. Dacă bifați opțiunea Includeți submodule, SmartGit va încărca automat toate modulele. Dacă bifați opțiunea „Preluare toate capetele și etichetele”, atunci SmartGit va descărca toate ramurile și etichetele pentru acest depozit după crearea folderului proiectului:
Rezumatul comenzilor practice
Dacă ați făcut tutorialul de mai sus, ar fi trebuit să lăsați cel puțin o mică îndoială în comenzile dvs. Cu toate acestea, dacă doriți deja să continuați studiile, aveți două opțiuni. „În acest articol, veți afla despre principalele sisteme centralizate și distribuite de gestionare și control al versiunilor și despre principalele sisteme utilizate astăzi pentru controlul versiunilor.”
Dvs. din domeniul tehnologiei ați participat deja la un proiect de dezvoltare a echipei și știți cât de dificil este să schimbați în mod constant fișiere între echipă. E-mail, încărcare în cloud, stilou, sunt utilizate pentru schimbul și schimbul de coduri. Un sistem de control al versiunilor este un sistem care înregistrează modificările aduse unui grup de fișiere, iar funcția sa principală este de a gestiona un proiect și de a crea diferite versiuni ale acestuia. Acesta oferă o mai simplă și metodă eficientă pentru ca echipa de dezvoltare să modifice aceeași bază de cod fără conflicte.
Următoarea fereastră este numele proiectului în SmartGit:
Dacă ați clonat un depozit gol (ca în acest articol), veți vedea următoarea fereastră:
Mergi mai departe. Să creăm un commit. Ce este un commit? Aceasta este o comitere de schimbări. Fiecare comitet „își amintește” ce anume ați schimbat și în orice moment puteți returna starea anterioară a fișierelor. Vă sfătuiesc să faceți un commit după fiecare modificare semnificativă, de exemplu, remedierea unei erori într-o funcție. Pentru a crea un commit, trebuie să schimbați ceva în proiect. Adăugați câteva fișiere în folderul proiectului:
Cu acesta, puteți vizualiza istoricul tuturor modificărilor făcute de echipă, puteți crea versiuni noi și restaura versiunile vechi ale proiectului. Trebuie amintit că sistemul de control poate funcționa pentru orice fișier de pe computer, chiar dacă este axat pe dezvoltare.
Primele tipuri de astfel de sisteme care au apărut au fost sisteme de control al versiunilor centralizate și funcționează după cum urmează: au un server bazat pe o arhitectură client-server, unde serverul, la rândul său, numit și depozit, conține toate fișierele proiectului. Prin urmare, dezvoltatorii ar trebui să descarce versiunea pe care doresc să o schimbe pe desktopul lor local după ce au terminat și să o încarce pe server. Cu acest sistem, a fost ușor de gestionat proiectul, deoarece echipa știe că fiecare modifică și menține istoricul versiunilor proiectului.
Acum puteți vedea modificările proiectului nostru în SmartGit:
Selectați ambele fișiere și faceți clic mai întâi pe „Etapă”, apoi pe „Comit”. De ce ar trebui să apăs Stage? Butonul Stage adaugă fișierele selectate la indexul curent. Dacă doriți să creați un commit pentru două fișiere, dar s-au schimbat, spuneți până la 5, selectați doar aceste două fișiere, apăsați „Stage”, care le va adăuga la index și după „Commit”. În acest fel, doar cele două fișiere selectate vor intra în commit.
Cu toate acestea, acest sistem are o singură ramură de dezvoltare, nu există posibilitatea ca diferite echipe să lucreze în paralel într-un singur proiect în diferite industrii. Un alt dezavantaj este că, deoarece există un singur server în structura acestui sistem, dacă rămâne în aer, nu va fi posibil să lucrați într-un grup în timpul perioadelor de nefuncționare.
Și apoi apar sisteme distribuite de control al versiunilor, în acest sistem, clienții nu mai copiază ultimele versiuni, dar scoțând întregul depozit. Care este cel mai bun instrument de utilizat? Acum, că știm cum funcționează aceste sisteme, vom lista principalele produse softwarecare sunt responsabili pentru funcționarea acestui sistem. Există multe sisteme și instrumente pentru controlul versiunilor astăzi, fiecare folosind o metodă diferită. Astfel, programele enumerate sunt software gratuit și funcționează la majoritatea sisteme de operare și sunt populare printre dezvoltatori.
După aceea, va apărea o fereastră în care va trebui să introduceți un comentariu pentru comitere. De obicei, ei scriu acolo ceea ce a fost modificat, adăugat, eliminat și așa mai departe:
Apoi ar trebui să apăsați butonul „Commit”. Butonul „Commit & Push” face același lucru, dar împinge (împinge) modificările la depozitul la distanță (în cazul nostru, acesta este Bitbucket). Nu o face încă. Ne vom ocupa de a împinge mai departe. Mai jos, în lista sucursalelor, va apărea ramura „master” locală. Aceasta este ramura principală a codului aplicației. O să vă spun puțin mai târziu ce sunt ramurile. Acum să facem ceva cu proiectul nostru și apoi să derulăm modificările. Voi șterge fișierul readme.txt, voi edita fișierul index.php și voi adăuga un nou fișier confic.cfg:
Te ajută să te descurci diferite versiuni proiectele tale. Servicii de control al versiunii codului. Acest articol este destinat companiilor și echipelor care nu au ales încă sau au în vedere schimbarea instrumentelor de control al versiunii. Există mai multe criterii pentru alegerea unui instrument de control al versiunilor.
Ușurință în utilizare. ... Criteriile pentru alegerea unui instrument pentru un proiect personal sunt diferite de criteriile pentru alegerea unei echipe sau a unei organizații. Pentru o echipă sau organizație, alegerile bazate doar pe popularitate pot duce la decizii inadecvate. Este important să cercetați dacă motivele popularității unei opțiuni sunt adecvate alegerii dvs.
Acum să revenim la schimbare după comitere. Să mergem la Log:
Selectați confirmarea la care doriți să reveniți și dați clic pe „Resetare”:
În fereastra următoare ni se oferă să alegem ce „Resetare” dorim să facem:
O sa explice. Amintiți-vă că atunci când creați un commit, mai întâi adăugați fișierele pe scenă. Acest lucru vă permite să comiteți numai fișierele indexate. Resetarea soft resetează numai comitetele. Rămâne indexul și modificările fizice ale fișierelor. Resetarea mixtă funcționează la fel ca software-ul, dar elimină și indexul fișierului. Resetarea hard elimină comitetele, indexul și modificările fizice ale fișierelor. Utilizați cu atenție resetarea hard, pentru a nu șterge accidental lucrurile inutile.
- Înregistrarea modificărilor proiectului.
- Permiterea colaborării.
- Crearea și sprijinirea modificărilor proiectului.
Aceasta este o etapă intermediară în pregătirea pentru pregătirea revizuirii. Un index este un element de infrastructură. În special pentru începători și utilizatori intermediari, puținele cazuri în care este utilă gestionarea directă a indexului nu depășesc efortul și complexitatea suplimentară, precum și riscurile de consolidare a unei alte configurații decât cea analizată și testată în directorul de lucru. Dacă Geet era o mașină, trebuie să înțelegeți cum funcționează motorul cu ardere internă pentru a învăța cum să o conduceți.
Am făcut o resetare hard pentru claritate:
După cum puteți vedea, toate modificările din fișiere au dispărut sau, mai bine zis, totul a revenit la starea primei comisii.
Acum puțin despre crearea de sucursale. De ce sunt deloc necesare? Sucursala vă permite să salvați starea curentă a codului și să experimentați. De exemplu, scrieți un nou modul. Este logic să faceți acest lucru într-o ramură separată. Șefii sună și spun că proiectul are o eroare și că trebuie reparat urgent, dar modulul dvs. nu a fost finalizat. Cum se încarcă fișiere care nu funcționează? Trebuie doar să treceți la ramura de lucru fără modul, să remediați eroarea și să încărcați fișierele pe server. Și când „pericolul” a trecut, continuați să lucrați la modul. Și acesta este unul dintre numeroasele exemple de beneficii ale sucursalelor.
Aceste comenzi sunt deseori denumite comenzi „sanitare”, iar cele mai ușoare comenzi de utilizat sunt numite comenzi „porțelan”. Chiar și aceste comenzi suferă de o utilizare slabă. Unele dintre ele nu funcționează conform așteptărilor în comparație cu conceptele clasice de control al versiunilor. Cu toate acestea, depozitul creat nu este utilizat direct, deoarece nu are un director de lucru corespunzător. De asemenea, documentația dvs. este considerată mai dificil de înțeles. O comandă incorectă executată de un dezvoltator neglijent sau neantrenat poate duce cu ușurință la situații foarte dificile care pot dispărea.
Să încercăm să ne creăm propria ramură. Avem deja unul, acesta este maestru. Este creat automat (dacă lipsește) atunci când faceți primul commit. Să creăm o altă ramură și să o numim „nou_futur1”. Apăsați F7 sau faceți clic dreapta în partea de jos în fila Filiale de pe inscripția Filiale locale și selectați Adăugați filială în lista derulantă:
Faceți clic pe „Adăugați ramură și comutați” pentru a trece imediat la ramura creată. Acum puteți crea noi confirmări, modificați fișiere și nu vă faceți griji. Din moment ce aveți întotdeauna o ramură principală la care să vă întoarceți. Când schimbați o ramură, Git se schimbă fisiere locale pe cele care se află în acest fir. Adică, dacă creați o ramură nouă, schimbați ceva în fișierul index.php și apoi treceți la ramura master, toate modificările pe care le-ați făcut vor fi șterse. Dacă reveniți la ramura creată, modificările vor fi anulate.
Deși pierderea codului este rară, este nevoie de o mulțime de cunoștințe tehnice pentru a remedia mizeria, mai ales după ce daunele au fost transmise altor dezvoltatori. Este important să rețineți că complexitatea excesivă și expunerea detaliată nu aduc nicio îmbunătățire a performanței și nici nu fac controlul versiunilor mai eficient.
Git este destul de dificil de învățat și de utilizat. Flagelul conflictului de interese este comun, în special în cazul dezvoltatorilor neantrenați. Cel mai important criteriu atunci când alegeți un instrument de control al versiunii este simplitatea, deoarece alte criterii sunt irelevante sau echivalente. Instrumentul simplu este că va face controlul versiunilor rapid și transparent.
Până acum am lucrat la nivel local. Să încercăm să încărcăm munca lucrării noastre pe server. Să creăm un fel de commit în ramura new_future1. Dacă depozitul este gol, dar este gol, deoarece l-am creat acum ceva timp și nu am încărcat nimic pe server, Bitbucket atribuie ramura principală care a fost încărcată mai întâi. Deci, să trecem la ramura „master” și să facem clic pe butonul „Push”:
Dacă echipa dvs. nu a adoptat încă un instrument de control al versiunilor, începeți cu cea mai simplă soluție care rezolvă problema. Apoi, dacă aveți cu adevărat nevoie de el, puteți trece de la un instrument la altul, refolosind istoricul. În lumea dezvoltării software o mulțime de probleme și bătălii se datorează lipsei controlului versiunii pentru orice produs în curs de dezvoltare. Majoritatea acestor probleme apar atunci când lucrăm în echipă și din motive.
Unii programatori ajung să modifice codul sursă al altora fără să ceară nimic, iar aceste modificări înlocuiesc codul anterior. Aici încep argumentele și discuțiile din echipă, deoarece toată lumea ajunge să creadă că codul lor anterior este mai util decât cel actual etc.
Apoi, SmartGit vă va întreba dacă puteți configura urmărirea cofigurării. Urmărirea vă permite să actualizați automat ramurile conexe atunci când descărcați sau încărcați actualizări de cod. Prin urmare, nu ezitați să faceți clic pe „Configurare”:
Acum treceți la o altă ramură și faceți același lucru. Accesați Bitbucket și vedeți ce s-a schimbat în secțiunea Commits:
Întrucât au apărut toate aceste probleme, ar fi bine dacă ar exista un loc în care toată lumea să își poată dezvolta codul sursă și s-ar face o estimare unde: care este mai bine pentru proiect? Pentru a rezolva aceste și alte probleme menționate mai sus în lumea dezvoltării, au apărut sistemele de control al versiunilor, vom adopta aici o mică abordare.
Cu alte cuvinte, scopul său este de a gestiona diferite versiuni ale unui document care se schimbă în timp. Deoarece multe dintre ele sunt utilizate în tehnologie și dezvoltare de software, mulți oameni cred că controlul versiunilor este utilizat doar pentru a înregistra modificările coduri sursă, dar poate fi folosit pentru a gestiona orice tip de fișier pe un computer.
După cum puteți vedea, totul a ajuns pe un server la distanță.
Acum să combinăm ramurile. De ce este nevoie de asta? Să luăm același exemplu cu un modul. Mai devreme sau mai târziu, îl veți adăuga și va trebui să adăugați codul modulului la codul principal al aplicației. Trebuie doar să îmbinați ramurile. Pentru a face acest lucru, comutați la ramura în care doriți să îmbinați codul. În cazul nostru, acesta este stăpânul. Apoi faceți clic dreapta pe ramura din care doriți să îmbinați codul și selectați „Merge”:
Sistem local de control al versiunilor
Oricum, utilizarea controlului versiunilor este o soluție foarte inteligentă și utilă în domeniul nostru. Aceasta este considerată una dintre cele mai simple metode de utilizare a controlului versiunilor, adică aici facem modificări pe care le putem specifica manual și cum funcționează: copierea și plasarea fișierelor în alte directoare computer localplasându-le în aceste directoare de multe ori.
Această metodă este foarte obișnuită, deoarece este simplă, dar putem uita adesea în ce director am salvat o copie. fișierul anterior, și este posibil să ne grăbim sau să nu fim atenți să înlocuim un catalog cu altul. Confruntați cu această dificultate, unii programatori au avut ideea de a dezvolta primul sistem de control al versiunilor care rulează local, controlând modificările de fișiere sub controlul versiunii.
Acum nu mai rămâne decât să împingeți modificările la ramura master la server. Încărcăm modificarea pe server în același mod ca înainte și obținem:
Asta este tot acest timp. Datorită pozelor, articolul a ieșit mare. Întrebați-vă răspunsurile. Scrie intrebari.
Știți cu toții sistemul Git. Cel puțin ai auzit - asta e sigur. Dezvoltatorii care folosesc sistemul fie îl adoră, fie îl critică pentru interfața sa complexă și bug-uri. Sistemul de control al versiunilor Git este standardul de facto al industriei. Este posibil ca dezvoltatorul să aibă păreri despre beneficiile Mercurial, dar cel mai adesea trebuie să vă supuneți cerinței de a vă familiariza cu Git. Ca orice sistem complex, are multe funcții utile și necesare. Cu toate acestea, nu toată lumea ajunge la o simplitate strălucitoare, astfel încât implementarea existentă a lăsat loc de îmbunătățire.
Tăcerea este un sistem care este încă utilizat pe scară largă astăzi. Așa cum am citat mai devreme în articol, dezvoltatorilor le-a fost greu să lucreze împreună. Aceste sisteme au fost proiectate cu accent pe facilitarea vieții dezvoltatorilor care doreau să lucreze în echipă. Acest sistem este stabil și a devenit standardul pentru controlul versiunilor de-a lungul anilor. Una dintre marile probleme cu care s-au confruntat dezvoltatorii cu acest tip de sistem a fost aceea că în fiecare vară erau centralizați pe o singură mașină și, dacă mașina respectivă devenea inoperantă, nimeni nu putea face nimic până când nu reveneau la normal, mare dependență între dezvoltator și server.
Cu cuvinte simple - aplicația complicată a fost dificil de utilizat. Prin urmare, în laboratorul Institutului de Tehnologie din Massachusetts, au preluat îmbunătățiri și au întrerupt toate „elementele problematice” (la urma urmei, ceea ce este o problemă pentru unul, pentru altul poate fi cu ușurință un avantaj). Versiunea îmbunătățită și simplificată se numește Gitless. A fost dezvoltat cu 2.400 de întrebări legate de Git preluate de pe site-ul dezvoltatorului StackOverflow.
Ce e în neregulă cu Git
Mulți utilizatori s-au plâns că Git are nevoie de o nouă interfață. Au realizat chiar și un document numit What's Wrong with Git? Analiza proiectării conceptuale. Autori: S. Perez De Rosso și D. Jackson.Exemplu
git checkout< file > // anulați toate modificările dintr-un singur fișier de la ultima încărcare în sistemul git reset - hard // anulați toate modificările din toate fișierele de la ultima încărcare în sistemAceste două linii sunt o ilustrare a cât de mult Git avea nevoie de o interfață îmbunătățită. Două comenzi diferite pentru o funcție, o diferență fiind că una este pentru un singur fișier și cealaltă este pentru mai multe fișiere. O parte a problemei este, de asemenea, că aceste două comenzi nu fac de fapt exact același lucru.
Majoritatea utilizatorilor Git o folosesc pentru un număr mic de comenzi, iar ceilalți rămași cunosc platforma la un nivel mai profund. Se pare că practic platforma este necesară pentru funcțiile de bază și că există un strat mare de posibilități pentru un cerc prea îngust. Acest lucru indică faptul că Git nu funcționează corect.
Scurtă comparație a funcțiilor de bază cu versiunea anterioară
Una dintre caracteristicile izbitoare ale Gitless este că ignoră o caracteristică numită punere în scenă. Vă permite să salvați părți separate ale fișierului. Convenabil, dar poate crea situații problematice. Diferența cheie între această funcție și funcția de ascundere este că a doua ascunde schimbările de la scenă.Funcția de ascundere ascunde lucrările brute în directorul de lucru - fișiere urmărite care s-au schimbat și salvează totul în stiva în așteptare. Toate modificările pot fi aplicate ulterior, atunci când este convenabil. Acest lucru este necesar atunci când lucrați într-o ramură și totul din ea este într-o stare dezordonată, dar trebuie să treceți urgent la o altă ramură. Nu doriți să verificați codul parțial realizat în prima ramură pe durata pauzei.
Funcția de etapizare indexează modificările aduse fișierului. Dacă ați marcat fișierele organizate, Git știe că le-ați pregătit pentru încărcare.
Nu există un concept ascuns în Gitless. Imaginați-vă următoarea situație. Vă aflați în mijlocul unui proiect și ar trebui să treceți la o altă ramură, dar nu ați verificat încă munca pe jumătate făcută. Funcția de stocare preia modificările pe care le-ați făcut și le salvează într-un teanc cu modificările în așteptare pe care le puteți restabili ulterior.
Autorul manualului Gitless raportează că problema apare la trecerea între ramuri. Poate fi dificil să ne amintim care stash sunt unde. Ei bine, partea de sus a tuturor acestor aspecte a fost că funcția nu ajută în cazul în care vă aflați în procesul de îmbinare, care include fișiere conflictuale. Aceasta este părerea lui Perez de Rosso.
Gitless rezolvă această problemă. Ramurile au devenit complet autonome unul în raport cu celălalt. Acest lucru face munca mult mai ușoară și permite dezvoltatorilor să evite confuzia de a comuta constant între sarcini.
Salvarea modificărilor
Gitless ascunde cu totul zona scenei, făcând procesul mai transparent și mai puțin complicat pentru utilizator. Există comenzi „commit” mult mai flexibile pentru rezolvarea problemelor. Mai mult, acestea vă vor permite să efectuați acțiuni precum alocarea segmentelor de cod pentru un commit.
În plus, puteți schimba clasificarea oricărui fișier în valori: urmărit, nu urmărit sau ignorat. Nu contează dacă acest fișier există sau nu în antet.
Ramificarea proceselor de dezvoltare
De bază, necesar pentru înțelegere versiune noua, idee: sucursalele din Gitless au devenit linii de dezvoltare complet independente. Fiecare dintre ele rămâne cu versiunea sa de lucru a fișierelor separat de celelalte. Nu există suprapuneri și nu există probleme. În orice moment treceți la o ramură diferită, conținutul spațiului dvs. de lucru este păstrat și fișierele legate de ramura de destinație sunt restaurate. Clasificarea fișierelor este, de asemenea, păstrată. Dacă un fișier este clasificat diferit pe două ramuri separate, atunci Gitless va lua în considerare acest lucru.
Pur și simplu, în versiunea Gitless, nu este nevoie să țineți cont de modificările descărcate care intră în conflict cu modificările din ramura de destinație.
De asemenea, puteți amâna rezolvarea situației de conflict dacă aveți o fuziune sau o siguranță de mijloc. Conflictul va rămâne până când veți reveni.
Lucrul cu depozite la distanță
Sincronizarea cu alte depozite este aceeași în ambele programe.
Un alt avantaj al noii versiuni este posibilitatea de a trece la cea veche fără a pierde codul. Mai mult, este posibil ca colegii dvs. să nu fie nici măcar conștienți de faptul că utilizați alt software.
Puteți găsi un ghid pentru lucrul cu Gitless pe site-ul oficial al aplicației. Documentația descrie următoarele: cum să creați un depozit, să salvați modificările; cum să lucrați cu sucursale; cum să utilizați etichete, să lucrați cu depozite la distanță.
Care este rezultatul
Rezultatul este o aplicație care păstrează funcționalitatea Git, dar în același timp este mai ușor de învățat și de utilizat de către echipele de dezvoltare. De fapt, au existat încercări de îmbunătățire a Git înainte de Gitless. Dar, potrivit lui Philip Guo (este profesor asistent de științe cognitive la UC San Diego), această versiune a atins pentru prima dată obiectivele de transformare a interfeței și rezolvarea de fapt a principalelor probleme.Proiectul a folosit metode riguroase pentru a crea software. Acest lucru este necesar pentru a izola deficiențele într-unul dintre cele mai utilizate proiecte software din lume. În trecut, mulți utilizatori au venit cu argumente ridicole pro și contra Git, dar niciunul dintre ei nu s-a bazat pe o abordare științifică.
Cu Gitless, devine clar că abordarea simplificării poate fi aplicată și altor sisteme complexe. De exemplu, Google Inbox și Dropbox.