Î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
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)
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:- Un fișier care a fost creat, dar care nu este încă adăugat în depozit are starea „ne urmărit”.
- Când facem modificări la fișierele care au fost deja adăugate în depozitul Git, atunci starea lor este „modificată”.
- 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”.
- 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ă”.
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
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.
git add *.txt
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"
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/
```
- 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
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"
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
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
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"
git merge feature/add-header
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:
- Modificările care au fost pe această linie în ramura master se regăsesc între „<<<<<<< HEAD” și „=======".
- Modificările care au fost în ramura feature/add-header se găsesc între „=======" și „>>>>>>> feature/add-header”.
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…
git clone https://github.com/romankh3/git-demo
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"
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.
GO TO FULL VERSION