Git vs GitHub - Ce este controlul versiunilor și cum funcționează?

Ați fost vreodată confuz de modul în care funcționează Git și GitHub? Nu vă supărați - nu sunteți singuri. Git și GitHub pot fi uneori complicate, dar până la sfârșitul acestei postări veți înțelege bine cele două.

La început, poate fi tentant să crezi că Git și GitHub sunt același lucru. Dar în realitate nu sunt. Într-adevăr, este posibil să utilizați Git fără GitHub! Și, în cele din urmă, cele două există în scopuri diferite.

Această postare va începe prin a arunca o privire bună asupra scopurilor Git și GitHub. Ulterior, vom afla despre principalele diferențe dintre aceste două tehnologii vitale.

Fără alte întrebări, să începem cu Git.

Ce este Git?

Git este un sistem de control al versiunii distribuite (DVCS) utilizat pentru a salva diferite versiuni ale unui fișier (sau set de fișiere), astfel încât orice versiune să poată fi recuperată după bunul plac.

Git facilitează, de asemenea, înregistrarea și compararea diferitelor versiuni de fișiere. Aceasta înseamnă că detaliile despre ce s-a schimbat, cine a schimbat ce sau cine a inițiat o problemă pot fi revizuite oricând.

Dar dacă Git este un sistem de control al versiunii distribuite, ce înseamnă exact acești termeni?

Ce înseamnă „distribuit”?

Termenul „distribuit” înseamnă că ori de câte ori îi instruiți Git să partajeze directorul unui proiect, Git nu partajează doar ultima versiune de fișier. În schimb, distribuie fiecare versiune pe care a înregistrat-o pentru acel proiect.

Acest sistem „distribuit” este în contrast puternic cu alte sisteme de control al versiunilor. Aceștia partajează doar orice versiune pe care un utilizator a verificat-o în mod explicit din baza de date centrală / locală.

Bine, deci „distribuit” înseamnă să distribuiți toate versiunile - nu doar câteva selectate - ale fișierelor unui proiect pe care Git le-a înregistrat. Dar ce este mai exact un sistem de control al versiunilor?

Ce este un sistem de control al versiunilor?

Un sistem de control al versiunilor (VCS) se referă la metoda utilizată pentru a salva versiunile unui fișier pentru referință ulterioară.

Intuitiv, mulți oameni deja versiunea de control proiectele lor prin redenumirea versiuni diferite ale aceluiași fișier în diferite moduri , cum ar fi blogScript.js, blogScript_v2.js, blogScript_v3.js, blogScript_final.js, blogScript_definite_final.js, și așa mai departe. Dar această abordare este predispusă la erori și ineficientă pentru proiectele de echipă.

De asemenea, urmărirea a ceea ce s-a schimbat, cine a schimbat-o și de ce a fost schimbat este un efort plictisitor cu această abordare tradițională. Acest lucru luminează importanța unui sistem de control al versiunilor fiabil și colaborativ precum Git.

Cu toate acestea, pentru a obține tot ce este mai bun din Git, este esențial să înțelegeți modul în care Git gestionează fișierele dvs.

Stări de fișiere în Git

În Git, există trei stări primare (condiții) în care un fișier poate fi: starea modificată , starea etapizată sau starea angajată .

Stare modificată

Un fișier în starea modificată este un fișier revizuit - dar neînregistrat (neînregistrat).

Cu alte cuvinte, fișierele în starea modificată sunt fișiere pe care le-ați modificat, dar nu ați instruit în mod explicit Git să le monitorizeze.

Stadiul etapizat

Fișierele în stadiul etapizat sunt fișiere modificate care au fost selectate - în starea lor curentă (versiune) - și sunt pregătite pentru a fi salvate (angajate) în .gitdepozit în timpul următorului instantaneu de validare.

Odată ce un fișier este pus în scenă, înseamnă că ați autorizat în mod explicit Git să monitorizeze versiunea fișierului respectiv.

Stat angajat

Fișierele în starea de angajare sunt fișiere stocate cu succes în .gitdepozit.

Astfel, un fișier angajat este un fișier în care ați înregistrat versiunea etapizată în directorul (folderul) Git.

Notă: Starea unui fișier determină locația în care Git îl va plasa.

Locațiile fișierelor

Există trei locuri cheie care pot locui versiunile unui fișier în timp ce controlează versiunea cu Git: directorul de lucru , zona intermediară sau directorul Git .

Director de lucru

Directorul de lucru este un folder local pentru fișierele unui proiect. Aceasta înseamnă că orice folder creat oriunde pe un sistem este un director de lucru.

Notă:

  • Fișierele în starea modificată se află în directorul de lucru.
  • Directorul de lucru este diferit de .gitdirector. Adică, creați un director de lucru în timp ce Git creează un .gitdirector.
  • Consultați acest articol de comparație pentru mai multe diferențe între cele două depozite.

Zona de organizare

Zona intermediară - denumită tehnic „index” în limbajul Git - este un fișier, de obicei situat în .gitdirector, care stochează informații despre fișierele următoare în linie pentru a fi transferate în .gitdirector.

Notă:

  • Fișierele în stadiul de etapizare se află în zona de etapizare.

Director Git

.gitDirectorul este directorul ( de asemenea , numit „depozit“) , care Git creează în interiorul directorul de lucru pe care l - au instruit pentru a urmări.

De asemenea, .gitfolderul este locul în care Git stochează bazele de date obiect și metadatele fișierelor (fișierelor) pe care i-ați instruit să le monitorizeze.

Notă:

  • .gitDirectorul este viața Git - este elementul copiat atunci când clona un depozit de la un alt calculator (sau dintr - o platformă on - line cum ar fi GitHub).
  • Fișierele aflate în starea de angajare se află în directorul Git.

Fluxul de lucru Git de bază

Lucrul cu sistemul de control al versiunilor Git arată cam așa:

Diagrama de bază a fluxului de lucru Git
  1. Modificați fișierele din directorul de lucru.

    Rețineți că orice fișier pe care îl modificați devine un fișier în starea modificată .

  2. Etapa selectivă a fișierelor pe care doriți să le trimiteți în .gitdirector.

    Rețineți că orice fișier pe care îl introduceți (adăugați) în zona de etapizare devine un fișier în starea de etapă .

    De asemenea, rețineți că fișierele etapizate nu sunt încă în .gitbaza de date.

    Stadierea înseamnă că informațiile despre fișierul etapizat sunt incluse într-un fișier (numit „index”) din .gitdepozit.

  3. Confirmați fișierele pe care le-ați aranjat în .gitdirector. Adică, stocați în permanență un instantaneu al fișierelor în etapă în .gitbaza de date.

    Rețineți că orice versiune de fișier pe care o trimiteți în .gitdirector devine un fișier în starea de angajare .

Esența până acum

Discuția lungă și scurtă de până acum este că Git este un sistem strălucit de control al versiunilor pentru versiuni, gestionare și distribuție de fișiere competente. Consultați acest ghid simplu pentru a afla cum să utilizați Git eficient.

Dar, stai puțin, dacă Git ajută la gestionarea și distribuirea eficientă a diferitelor versiuni ale fișierului unui proiect, care este scopul GitHub?

GitHub Demystified

GitHub este o platformă bazată pe web în care utilizatorii pot găzdui depozite Git. Vă ajută să facilitați partajarea ușoară și colaborarea la proiecte cu oricine în orice moment.

GitHub încurajează, de asemenea, o participare mai largă la proiectele open-source, oferind un mod sigur de editare a fișierelor din depozitul unui alt utilizator.

Pentru a găzdui (sau a partaja) un depozit Git pe GitHub, urmați pașii de mai jos:

Pasul 1: Creați un cont GitHub

Primul pas pentru a începe găzduirea pe GitHub este crearea unui cont personal. Accesați pagina oficială de înregistrare pentru a vă înscrie.

Pasul 2: Creați un depozit la distanță în GitHub

După ce v-ați înscris pentru un cont, creați o casă (un depozit) în GitHub pentru depozitul Git pe care doriți să îl partajați.

Pasul 3: Conectați directorul Git al proiectului la depozitul la distanță

După ce ați creat un depozit la distanță pentru proiectul dvs., conectați .gitdirectorul proiectului - situat local pe sistemul dvs. - cu depozitul la distanță de pe GitHub.

Pentru a vă conecta la depozitul la distanță, intrați în directorul rădăcină al proiectului pe care doriți să îl partajați prin terminalul local și rulați:

git remote add origin //github.com/yourusername/yourreponame.git

Notă:

  • Înlocuiți yourusernamecodul de mai sus cu numele dvs. de utilizator GitHub.

    În mod similar, înlocuiți yourreponamecu numele depozitului la distanță la care doriți să vă conectați.

  • Comanda de mai sus implică faptul că git ar trebui să adauge adresa URL specificată la proiectul local ca referință la distanță cu care .gitdirectorul local poate interacționa.
  • originOpțiunea în comanda de mai sus este numele implicit (un nume scurt) Git oferă găzduirea depozitul de la distanță server.

    Adică, în loc de adresa URL a serverului, Git folosește numele scurt origin.

  • Nu este obligatoriu să rămâneți cu numele implicit al serverului. Dacă preferați un alt nume decât origin, înlocuiți pur și simplu originnumele din git remote addcomanda de mai sus cu orice nume preferați.
  • Amintiți-vă întotdeauna că numele scurt al unui server (de exemplu,   origin) nu este nimic special! Există doar - la nivel local - pentru a vă ajuta să consultați cu ușurință adresa URL a serverului. Așadar, simțiți-l să îl schimbați într-un nume scurt pe care îl puteți face cu ușurință.
  • Pentru a redenumi orice adresă URL existentă la distanță, utilizați git remote renamecomanda astfel:
git remote rename theCurrentURLName yourNewURLName
  • Ori de câte ori clonați (descărcați) orice repo la distanță, Git numește automat adresa URL a repo origin. Cu toate acestea, puteți specifica un alt nume cu git clone -o yourPreferredNamecomanda.
  • Pentru a vedea URL-ul exact stocat pentru porecle cum ar fi origin, executați git remote -vcomanda.

Pasul 4: Confirmați conexiunea

După ce v-ați conectat directorul Git la depozitul de la distanță, verificați dacă conexiunea a avut succes rulând git remote -vpe linia de comandă.

Apoi, verificați ieșirea pentru a confirma că adresa URL afișată este aceeași cu adresa URL la distanță la care intenționați să vă conectați.

Notă:

  • Consultați articolul „Conectarea cu SSH” dacă doriți să vă conectați utilizând adresa URL SSH în loc de adresa URL HTTPS.
  • Cu toate acestea, dacă nu sunteți sigur de adresa URL la distanță de utilizat, consultați „Ce adresă URL la distanță ar trebui să folosesc?” articol.
  • Doriți să modificați adresa URL la distanță? Schimbarea adresei URL a unei telecomenzi este un ghid excelent.

Pasul 5: împingeți o repo Git locală la repo la distanță

După ce ați conectat cu succes directorul local la depozitul la distanță, puteți începe să împingeți (încărcați) proiectul local în amonte.

Ori de câte ori sunteți gata să vă partajați proiectul în altă parte, pe orice repo la distanță, pur și simplu instruiți-l pe Git să împingă toate comitetele, ramurile și fișierele din .gitdirectorul dvs. local către depozitul la distanță.

Sintaxa codului utilizată pentru a încărca (împinge) un director Git local într-un depozit la distanță este git push -u remoteName branchName.

Adică, pentru a împinge .gitdirectorul local și, presupunând că numele scurt al adresei URL la distanță este „origine”, rulați:

git push -u origin master

Notă:

  • Comanda de mai sus implică faptul că Git ar trebui să împingă locală maestru ramură la distanță de master sucursală situată la URL - ul numit origine .
  • Din punct de vedere tehnic, puteți înlocui originopțiunea cu adresa URL a depozitului la distanță. Amintiți-vă, originopțiunea este doar o poreclă a adresei URL pe care ați înregistrat-o în .gitdirectorul dvs. local .
  • -uPavilion (amonte de urmărire / pavilion de referință) leagă automat .gitfiliala locală cu directorul sucursalei de la distanță. Acest lucru vă permite să utilizați git pullfără niciun argument.

Pasul 6: Confirmați încărcarea

În cele din urmă, reveniți la pagina depozitului dvs. GitHub pentru a confirma că Git a împins cu succes directorul local Git în depozitul la distanță.

Notă:

  • Poate fi necesar să reîmprospătați pagina depozitului la distanță pentru ca modificările să fie reflectate.
  • GitHub are, de asemenea, o facilitate gratuită opțională pentru a vă converti depozitul la distanță într-un site web funcțional. Să vedem „cum” mai jos.

Publicați site-ul dvs. web cu pagini GitHub

După ce v-ați împins proiectul către depozitul dvs. la distanță, îl puteți publica cu ușurință pe web astfel:

  1. Asigurați-vă că numele fișierului HTML principal al proiectului dvs. este index.html.
  2. Pe platforma site-ului web GitHub, accesați depozitul proiectului pe care doriți să îl publicați și faceți clic pe fila de setări a depozitului .
  3. Derulați în jos la secțiunea Pagini GitHub și schimbați ramura Sursă de la none la master .
  4. Apoi, se va afișa o notificare care va spune: „Site-ul dvs. este publicat la //numele-utilizator.github.io/numele-github-repo-// ”.
  5. Acum puteți vizualiza - și face publicitate - proiectul dvs. la adresa URL specificată.

Această secțiune a zgâriat doar suprafața publicării proiectului dvs. cu GitHub. Pentru a afla mai multe despre paginile GitHub, consultați această documentație „Lucrul cu paginile GitHub”.

Pe scurt

GitHub este o platformă online pentru găzduirea (sau partajarea) depozitelor Git. Vă ajută să creați o cale de a colabora cu ușurință la proiecte cu oricine, în orice loc, în orice moment.

Încă aveți dubii?

Ești încă perplex cu privire la linia subțire dintre Git și GitHub? Nu-ți face griji - te-am acoperit. Mai jos sunt cinci diferențe cheie între Git și GitHub.

Diferența 1: Git vs. GitHub - Funcția primară

Git este un sistem de control al versiunilor distribuite care înregistrează diferite versiuni ale unui fișier (sau set de fișiere). Permite utilizatorilor să acceseze, să compare, să actualizeze și să distribuie oricare dintre versiunile înregistrate în orice moment.

Cu toate acestea, GitHub este în principal o platformă de găzduire pentru găzduirea de depozite Git online. Permite utilizatorilor să își păstreze depozitul la distanță privat sau deschis pentru eforturi de colaborare.

Diferența 2: Git vs. GitHub - Platforma de operare

Utilizatorii instalează și operează Git pe mașinile lor locale. Aceasta înseamnă că majoritatea operațiunilor Git sunt realizabile fără internet.

Cu toate acestea, GitHub este un serviciu web care funcționează exclusiv online. Aceasta înseamnă că aveți nevoie de internet pentru a face orice pe GitHub.

Diferența 3: Git vs. GitHub - Inventatori

Linus Torvalds a început dezvoltarea Git în aprilie 2005.

Chris Wanstrath, PJ Hyett, Tom Preston-Werner și Scott Chacon au fondat GitHub.com în februarie 2008.

Diferența 4: Git vs. GitHub - Mentenanți

În iulie 2005, Linus Torvalds i-a predat întreținerea lui Git lui Junio ​​C. Hamano - care este întreținătorul șef de atunci.

Și Microsoft a achiziționat GitHub în octombrie 2018.

Diferența 5: Git vs. GitHub - Concurenți

Alternativele populare față de Git sunt Mercurial, Team Foundation Version Control (TFVC), Perforce Helix Core, Apache Subversion și IBM Rational ClearCase.

Cei mai apropiați concurenți ai GitHub sunt GitLab, Bitbucket, SourceForge, Cloud Source Repositories și AWS CodeCommit.

În întregime

Git și GitHub sunt două entități diferite care vă ajută să gestionați și să găzduiți fișiere. Cu alte cuvinte, Git servește la controlul versiunilor de fișiere, în timp ce GitHub este o platformă pentru găzduirea depozitelor Git.

Resursă utilă

  • Cum se folosește Git - Un ghid uimitor cu sfaturi minunate