Noțiuni introductive cu Git: un ghid cuprinzător pentru începători

În loc de o introducere

Buna ziua! Astăzi vom vorbi despre un sistem de control al versiunilor și anume Git. Nu ai nimic de-a face cu programarea dacă nu cunoști/înțelegi Git. Dar frumusețea este că nu trebuie să ții în cap toate comenzile și funcțiile Git pentru a fi folosit continuu. Trebuie să cunoașteți un set de comenzi care vă vor ajuta să înțelegeți tot ce se întâmplă.

Bazele Git

Git este un sistem distribuit de control al versiunilor pentru codul nostru. De ce avem nevoie de ea? Echipele distribuite au nevoie de un fel de sistem pentru a-și gestiona munca. Este necesar să urmăriți schimbările care apar în timp. Adică, trebuie să putem vedea pas cu pas ce fișiere s-au schimbat și cum. Acest lucru este deosebit de important atunci când investigați ce sa schimbat în contextul unei singure sarcini, făcând posibilă anularea modificărilor.

Instalarea Git

Să instalăm Java pe computer.

Instalare pe Windows

Ca de obicei, trebuie să descărcați și să rulați un fișier exe. Totul este simplu aici: faceți clic pe primul link Google , efectuați instalarea și gata. Pentru a face acest lucru, vom folosi consola bash furnizată de Windows. Pe Windows, trebuie să rulați Git Bash. Iată cum arată în meniul Start: Acum acesta este un prompt de comandă cu care puteți lucra. Pentru a evita de fiecare dată să mergeți în folderul cu proiectul pentru a deschide Git acolo, puteți deschide promptul de comandă din folderul proiectului cu butonul din dreapta al mouse-ului cu calea de care avem nevoie:

Instalare pe Linux

De obicei, Git face parte din distribuțiile Linux și este deja instalat, deoarece este un instrument care a fost scris inițial pentru dezvoltarea nucleului Linux. Dar sunt situații când nu este. Pentru a verifica, trebuie să deschideți un terminal și să scrieți: git --version. Dacă obțineți un răspuns inteligibil, atunci nu trebuie instalat nimic. Deschideți un terminal și instalați Git pe Ubuntu . Lucrez pe Ubuntu, așa că vă pot spune ce să scrieți pentru el: sudo apt-get install git.

Instalare pe macOS

Și aici, mai întâi trebuie să verificați dacă Git este deja acolo. Dacă nu îl aveți, atunci cel mai simplu mod de a-l obține este să descărcați cea mai recentă versiune de aici . Dacă Xcode este instalat, atunci Git va fi cu siguranță instalat automat.

Setări Git

Git are setări de utilizator pentru utilizatorul care va trimite lucrări. Acest lucru are sens și este necesar, deoarece Git preia aceste informații pentru câmpul Autor atunci când este creat un commit. Configurați un nume de utilizator și o parolă pentru toate proiectele dvs. rulând următoarele comenzi:

git config --global user.name "Ivan Ivanov"
git config --global user.email ivan.ivanov@gmail.com

Dacă trebuie să schimbați autorul pentru un anumit proiect, puteți elimina „--global”. Acest lucru ne va oferi următoarele:

git config user.name "Ivan Ivanov"
git config user.email ivan.ivanov@gmail.com

Un pic de teorie...

Pentru a aborda subiectul, ar trebui să vă prezentăm câteva cuvinte și acțiuni noi...

• depozitul git
• comite
• ramură
• combina
• conflicte
• Trage
• Apăsaţi
• cum să ignori unele fișiere (.gitignore)

Și așa mai departe.

Stări în Git

Git are mai multe statui care trebuie înțelese și reținute:

• neurmată
• modificat
• pus în scenă
• comise

Cum ar trebui să înțelegi asta?

Acestea sunt stările care se aplică fișierelor care conțin codul nostru:

1. Un fișier care a fost creat, dar care nu este încă adăugat în depozit are starea „ne urmărit”.
2. Când facem modificări la fișierele care au fost deja adăugate în depozitul Git, atunci starea lor este „modificată”.
3. Dintre fișierele pe care le-am schimbat, le selectăm pe cele de care avem nevoie, iar aceste clase sunt modificate în starea „în etape”.
4. O comitere este creată din fișiere pregătite în starea în etapă și intră în depozitul Git. După aceea, nu există fișiere cu starea „în etapă”. Dar pot exista în continuare fișiere a căror stare este „modificată”.

Iată cum arată:

Ce este un commit?

Un commit este evenimentul principal atunci când vine vorba de controlul versiunilor. Conține toate modificările făcute de la începutul comiterii. Commit-urile sunt legate între ele ca o listă unică. Mai precis: există un prim commit. Când este creat al doilea commit, știe ce urmează după primul. Și în acest mod, informațiile pot fi urmărite. Un commit are, de asemenea, propriile informații, așa-numitele metadate:

• identificatorul unic al comiterii, care poate fi folosit pentru a-l găsi
• numele autorului comisiei, care a creat-o
• data la care a fost creat commit-ul
• un comentariu care descrie ceea ce s-a făcut în timpul comiterii

Iată cum arată:

Ce este o ramură?

O ramură este un indicator către o comitere. Deoarece un commit știe care commit îl precede, atunci când o ramură indică un commit, toate acele comitere anterioare se aplică și ei. În consecință, am putea spune că puteți avea atâtea ramuri câte doriți, indicând același commit. Lucrarea are loc în ramuri, așa că atunci când este creat un nou commit, ramura își mută indicatorul spre commit-ul mai recent.

Începeți cu Git

Puteți lucra atât cu un depozit local, cât și cu unul la distanță. Pentru a exersa comenzile necesare, vă puteți limita la depozitul local. Stochează doar local toate informațiile proiectului în folderul .git. Dacă vorbim despre depozitul de la distanță, atunci toate informațiile sunt stocate undeva pe serverul de la distanță: doar o copie a proiectului este stocată local. Modificările aduse copiei dvs. locale pot fi trimise (git push) în depozitul de la distanță. În discuția noastră de aici și de mai jos, vorbim despre lucrul cu Git în consolă. Desigur, puteți utiliza un fel de soluție bazată pe GUI (de exemplu, IntelliJ IDEA), dar mai întâi ar trebui să vă dați seama ce comenzi sunt executate și ce înseamnă acestea.

Lucrul cu Git într-un depozit local

În continuare, vă sugerez să urmați și să efectuați toți pașii pe care i-am făcut în timp ce citiți articolul. Acest lucru vă va îmbunătăți înțelegerea și stăpânirea materialului. Ei bine, pofta buna! :) Pentru a crea un depozit local, trebuie să scrieți:

git init

Aceasta va crea un folder .git în directorul curent al consolei. Dosarul .git stochează toate informațiile despre depozitul Git. Nu-l șterge ;) Apoi, fișierele sunt adăugate la proiect și li se atribuie starea „Ne urmărit”. Pentru a verifica starea actuală a lucrării dvs., scrieți asta:

git status

Suntem în ramura master, și aici vom rămâne până când trecem la o altă ramură. Aceasta arată ce fișiere s-au modificat, dar nu au fost încă adăugate la starea „în etape”. Pentru a le adăuga la starea „în scenă”, trebuie să scrieți „git add”. Avem aici câteva opțiuni, de exemplu:

• git add -A — adaugă toate fișierele la starea „în scenă”.
• git add . — adăugați toate fișierele din acest folder și toate subfolderele. În esență, acesta este același cu cel precedent
• git add <nume fișier> — adaugă un anumit fișier. Aici puteți folosi expresii regulate pentru a adăuga fișiere conform unui model. De exemplu, git add *.java: Aceasta înseamnă că doriți doar să adăugați fișiere cu extensia java.

Primele două opțiuni sunt clar simple. Lucrurile devin mai interesante cu cea mai recentă adăugare, așa că hai să scriem:

git add *.txt

Pentru a verifica starea, folosim comanda deja cunoscută nouă:

git status

Aici puteți vedea că expresia regulată a funcționat corect: test_resource.txt are acum starea „în etape”. Și, în sfârșit, ultima etapă pentru lucrul cu un depozit local (mai există unul când lucrați cu depozitul de la distanță ;)) - crearea unui nou commit:

git commit -m "all txt files were added to the project"

Următorul este o comandă grozavă pentru a vedea istoricul comitării pe o ramură. Să folosim de el:

git log

Aici puteți vedea că am creat primul nostru commit și include textul pe care l-am furnizat pe linia de comandă. Este foarte important de înțeles că acest text ar trebui să explice cât mai exact posibil ceea ce s-a făcut în timpul acestui comit. Acest lucru ne va ajuta de multe ori în viitor. Un cititor curios care nu a adormit încă se poate întreba ce s-a întâmplat cu fișierul GitTest.java. Să aflăm chiar acum. Pentru a face acest lucru, folosim:

git status

După cum puteți vedea, este încă „netrasă” și așteaptă în aripi. Dar dacă nu vrem deloc să-l adăugăm la proiect? Uneori se întâmplă asta. Pentru a face lucrurile mai interesante, acum să încercăm să schimbăm fișierul test_resource.txt. Să adăugăm ceva text acolo și să verificăm starea:

git status

Aici puteți vedea clar diferența dintre stările „ne urmărit” și „modificat”. GitTest.java este „ne urmărit”, în timp ce test_resource.txt este „modificat”. Acum că avem fișiere în starea modificată, putem examina modificările aduse acestora. Acest lucru se poate face folosind următoarea comandă:

git diff

Adică, puteți vedea clar aici ce am adăugat la fișierul nostru text: hello world! Să adăugăm modificările noastre la fișierul text și să creăm un commit:

git add test_resource.txt
git commit -m "added hello word! to test_resource.txt"

Pentru a vedea toate commit-urile, scrieți:

git log

După cum puteți vedea, acum avem două comisii. Vom adăuga GitTest.java în același mod. Fără comentarii aici, doar comenzi:

git add GitTest.java
git commit -m "added GitTest.java"
git status

Lucrul cu .gitignore

În mod clar, vrem doar să păstrăm codul sursă singur, și nimic altceva, în depozit. Deci ce altceva ar putea fi? Cel puțin, clase compilate și/sau fișiere generate de mediile de dezvoltare. Pentru a-i spune lui Git să le ignore, trebuie să creăm un fișier special. Faceți acest lucru: creați un fișier numit .gitignore în rădăcina proiectului. Fiecare linie din acest fișier reprezintă un model de ignorat. În acest exemplu, fișierul .gitignore va arăta astfel:

```
*.class
target/
*.iml
.idea/
```

Hai să aruncăm o privire:

• Prima linie este să ignorați toate fișierele cu extensia .class
• A doua linie este să ignori folderul „țintă” și tot ceea ce conține
• A treia linie este să ignorați toate fișierele cu extensia .iml
• A patra linie este să ignorați folderul .idea

Să încercăm să folosim un exemplu. Pentru a vedea cum funcționează, să adăugăm GitTest.class compilat la proiect și să verificăm starea proiectului:

git status

În mod clar, nu vrem să adăugăm în mod accidental clasa compilată în proiect (folosind git add -A). Pentru a face acest lucru, creați un fișier .gitignore și adăugați tot ce a fost descris mai devreme: Acum să folosim un commit pentru a adăuga fișierul .gitignore la proiect:

git add .gitignore
git commit -m "added .gitignore file"

Și acum este momentul adevărului: avem o clasă compilată GitTest.class care este „untracked”, pe care nu am vrut să o adăugăm la depozitul Git. Acum ar trebui să vedem efectele fișierului .gitignore:

git status

Perfect! .gitignore +1 :)

Lucrul cu ramuri și altele

Desigur, lucrul într-o singură ramură este incomod pentru dezvoltatorii solitari și este imposibil atunci când există mai multe persoane într-o echipă. De aceea avem filiale. După cum am spus mai devreme, o ramură este doar un indicator mobil către comite. În această parte, vom explora lucrul în diferite ramuri: cum să îmbinați modificările de la o ramură în alta, ce conflicte pot apărea și multe altele. Pentru a vedea o listă cu toate ramurile din depozit și pentru a înțelege în care dintre ramuri vă aflați, trebuie să scrieți:

git branch -a

Puteți vedea că avem doar o ramură principală. Asteriscul din fața lui indică faptul că suntem în el. Apropo, puteți folosi și comanda „git status” pentru a afla în ce ramură ne aflăm. Apoi există mai multe opțiuni pentru a crea ramuri (pot fi mai multe — acestea sunt cele pe care le folosesc):

• creați o nouă filială pe baza celei în care ne aflăm (99% din cazuri)
• creați o ramură bazată pe un anumit commit (1% din cazuri)

Să creăm o ramură bazată pe un anumit commit

Ne vom baza pe identificatorul unic al comiterii. Pentru a-l găsi, scriem:

git log

Am evidențiat commit-ul cu comentariul „adăugat salut lume...” Identificatorul său unic este 6c44e53d06228f888f2f454d3cb8c1c976dd73f8. Vreau să creez o ramură de „dezvoltare” care să pornească de la acest commit. Pentru a face asta, scriu:

git checkout -b development 6c44e53d06228f888f2f454d3cb8c1c976dd73f8

O ramură este creată doar cu primele două comite din ramura principală. Pentru a verifica acest lucru, mai întâi ne asigurăm că comutăm la o altă ramură și ne uităm la numărul de comiteri de acolo:

git status
git log

Și așa cum era de așteptat, avem două comisii. Apropo, iată un punct interesant: nu există încă niciun fișier .gitignore în această ramură, așa că fișierul nostru compilat (GitTest.class) este acum evidențiat cu starea „ne urmărit”. Acum ne putem revizui din nou filialele scriind asta:

git branch -a

Puteți observa că există două ramuri: „master” și „dezvoltare”. În prezent suntem în dezvoltare.

Să creăm o ramură bazată pe cea actuală

A doua modalitate de a crea o ramură este să o creezi din alta. Vreau să creez o ramură bazată pe ramura principală. În primul rând, trebuie să trec la el, iar următorul pas este să creez unul nou. Hai să aruncăm o privire:

• git checkout master — comută la ramura principală
• git status — verificați dacă suntem de fapt în ramura principală

Aici puteți vedea că am trecut la ramura master, fișierul .gitignore este în vigoare, iar clasa compilată nu mai este evidențiată ca „untracked”. Acum creăm o nouă ramură bazată pe ramura principală:

git checkout -b feature/update-txt-files

Dacă nu sunteți sigur dacă această ramură este aceeași cu „master”, puteți verifica cu ușurință executând „git log” și uitându-vă la toate commit-urile. Ar trebui să fie patru.

Rezolvarea conflictului

Înainte de a explora ce este un conflict, trebuie să vorbim despre fuzionarea unei ramuri în alta. Această imagine prezintă procesul de îmbinare a unei ramuri în alta: Aici avem o ramură principală. La un moment dat, o ramură secundară este creată din ramura principală și apoi modificată. Odată ce lucrarea este terminată, trebuie să unim o ramură în cealaltă. Nu voi descrie diferitele caracteristici: în acest articol, vreau doar să transmit o înțelegere generală. Dacă aveți nevoie de detalii, le puteți căuta singur. În exemplul nostru, am creat ramura feature/update-txt-files. După cum indică numele sucursalei, actualizăm textul. Acum trebuie să creăm un nou commit pentru această lucrare:

git add *.txt 
git commit -m "updated txt files"
git log

Acum, dacă vrem să îmbinăm ramificația feature/update-txt-files în master, trebuie să mergem la master și să scriem „git merge feature/update-txt-files”:

git checkout master
git merge feature/update-txt-files
git log

Drept urmare, ramura principală include acum și commit-ul care a fost adăugat la fișierele feature/update-txt. Această funcționalitate a fost adăugată, astfel încât să puteți șterge o ramură de caracteristică. Pentru a face acest lucru, scriem:

git branch -D feature/update-txt-files

Totul este clar până acum, da? Să complicăm situația: acum să spunem că trebuie să schimbi din nou fișierul txt. Dar acum acest fișier va fi modificat și în ramura principală. Cu alte cuvinte, se va schimba în paralel. Git nu va putea să-și dea seama ce să facă atunci când dorim să îmbinăm noul nostru cod în ramura principală. Să mergem! Vom crea o nouă ramură bazată pe master, vom face modificări la text_resource.txt și vom crea un commit pentru această lucrare:

git checkout -b feature/add-header
... we make changes to the file

git add *.txt
git commit -m "added header to txt"

Accesați ramura principală și, de asemenea, actualizați acest fișier text pe aceeași linie ca și în ramura caracteristică:

git checkout master
… we updated test_resource.txt

git add test_resource.txt
git commit -m "added master header to txt"

Și acum cel mai interesant punct: trebuie să îmbinăm modificările de la ramura caracteristică/adăugare antet la master. Suntem în ramura master, așa că trebuie doar să scriem:

git merge feature/add-header

Dar rezultatul va fi un conflict în fișierul test_resource.txt: Aici putem vedea că Git nu a putut decide singur cum să îmbine acest cod. Ne spune că trebuie să rezolvăm mai întâi conflictul și abia apoi să executăm comiterea. BINE. Deschidem fișierul cu conflictul într-un editor de text și vedem: Pentru a înțelege ce a făcut Git aici, trebuie să ne amintim ce modificări am făcut și unde, apoi comparăm:

1. Modificările care au fost pe această linie în ramura master se regăsesc între „<<<<<<< HEAD” și „=======".
2. Modificările care au fost în ramura feature/add-header se găsesc între „=======" și „>>>>>>> feature/add-header”.

Acesta este modul în care Git ne spune că nu și-a dat seama cum să efectueze îmbinarea în această locație din fișier. A împărțit această secțiune în două părți din diferite ramuri și ne invită să rezolvăm singuri conflictul de fuziune. Destul de corect. Mă hotărăsc cu îndrăzneală să elimin totul, lăsând doar cuvântul „antet”: Să ne uităm la starea modificărilor. Descrierea va fi ușor diferită. Mai degrabă decât un statut „modificat”, am „necontopit”. Deci am fi putut menționa un al cincilea statut? Nu cred că acest lucru este necesar. Să vedem:

git status

Ne putem convinge că acesta este un caz special, neobișnuit. Hai sa continuăm:

git add *.txt

Este posibil să observați că descrierea sugerează să scrieți doar „git commit”. Să încercăm să scriem asta:

git commit

Și tocmai așa, am făcut-o - am rezolvat conflictul în consolă. Desigur, acest lucru se poate face puțin mai ușor în mediile de dezvoltare integrate. De exemplu, în IntelliJ IDEA, totul este configurat atât de bine încât puteți efectua toate acțiunile necesare chiar în cadrul acestuia. Dar IDE-urile fac o mulțime de lucruri „sub capotă” și adesea nu înțelegem ce se întâmplă exact acolo. Și când nu există înțelegere, pot apărea probleme.

Lucrul cu depozite de la distanță

Ultimul pas este să descoperi câteva comenzi suplimentare care sunt necesare pentru a lucra cu depozitul de la distanță. După cum am spus, un depozit la distanță este un loc în care depozitul este stocat și din care îl puteți clona. Ce fel de depozite la distanță există? Exemple:

• GitHub este cea mai mare platformă de stocare pentru depozite și dezvoltare colaborativă. Am descris-o deja în articolele anterioare.
  Urmărește-mă pe GitHub . Adesea îmi arăt munca acolo în acele domenii pe care le studiez pentru muncă.

• GitLab este un instrument bazat pe web pentru ciclul de viață DevOps cu sursă deschisă . Este un sistem bazat pe Git pentru gestionarea depozitelor de cod cu propriul său wiki, sistem de urmărire a erorilor , conductă CI/CD și alte funcții.
  După știrea că Microsoft a cumpărat GitHub, unii dezvoltatori și-au duplicat proiectele în GitLab.

• BitBucket este un serviciu web pentru găzduirea proiectelor și dezvoltarea colaborativă bazat pe sistemele de control al versiunilor Mercurial și Git. La un moment dat, avea un mare avantaj față de GitHub prin faptul că oferea depozite private gratuite. Anul trecut, GitHub a introdus, de asemenea, această capacitate pentru toată lumea gratuit.

• Și așa mai departe…

Când lucrați cu un depozit de la distanță, primul lucru de făcut este să clonați proiectul în depozitul dvs. local. Pentru aceasta, am exportat proiectul pe care l-am realizat local, iar acum toată lumea îl poate clona singur scriind:

git clone https://github.com/romankh3/git-demo

Există acum o copie locală completă a proiectului. Pentru a vă asigura că copia locală a proiectului este cea mai recentă, trebuie să extrageți proiectul scriind:

git pull

În cazul nostru, nimic din depozitul de la distanță nu s-a schimbat în prezent, așa că răspunsul este: Deja actualizat. Dar dacă fac modificări în depozitul de la distanță, cel local este actualizat după ce le extragem. Și, în sfârșit, ultima comandă este de a împinge datele în depozitul de la distanță. Când am făcut ceva local și dorim să-l trimitem la depozitul de la distanță, trebuie mai întâi să creăm un nou commit local. Pentru a demonstra acest lucru, haideți să adăugăm altceva în fișierul text: Acum, ceva destul de comun pentru noi - creăm un commit pentru această lucrare:

git add test_resource.txt
git commit -m "prepared txt for pushing"

Comanda pentru a trimite acest lucru în depozitul de la distanță este:

git push

Ei bine, asta e tot ce am vrut să spun. Mulțumesc pentru atenție. Urmărește-mă pe GitHub , unde postez diverse exemple de proiecte interesante legate de studiul și munca mea personală.

Link util

• Documentație oficială Git . Il recomand ca referinta.