Cum să ușurați fluxul de lucru de dezvoltare al echipei dvs. cu Git Hooks

Una dintre cerințele majore de lucru pentru o echipă sau un proiect open-source este utilizarea unui sistem de control al versiunilor (VCS). Git este un sistem de control al versiunilor distribuit gratuit și open-source pentru urmărirea modificărilor codului sursă în timpul dezvoltării software. A fost creat de Linus Torvalds în 2005 pentru dezvoltarea nucleului Linux. Este ușor de învățat și are o amprentă mică, cu o performanță fulgerătoare.

Există o șansă mare să fi folosit deja Git (deoarece este unul dintre cele mai populare și bine adoptate instrumente VCS disponibile în comunitatea de dezvoltare) și, cel mai probabil, aveți deja anumite cunoștințe despre organizarea și comiterea codului dvs. prin împingere și tragere. acesta dintr-un depozit de la distanță. Acest articol nu va aborda elementele de bază ale fluxurilor de lucru git, ci se va concentra în principal pe cârligele git și cum să le utilizați pentru a obține o colaborare mai bună în echipa dvs. Odată cu creșterea dimensiunii echipelor, devine și mai important să menținem colaboratorii la linie și să menținem reguli diferite despre cod.

Ce sunt Git Hooks?

Cârligele Git sunt scripturi care sunt declanșate atunci când anumite acțiuni sau evenimente sunt efectuate într-un depozit git. Aceste acțiuni se referă la părți ale fluxului de lucru pentru controlul versiunilor, cum ar fi comiterea și împingerea. Cârligele pot fi cu adevărat utile prin automatizarea sarcinilor din fluxul de lucru git. De exemplu, ele ne pot ajuta să validăm sintaxa bazei de cod pe baza unor reguli specifice sau să rulăm unele teste înainte de a ne efectua modificările.

Cum să le setați?

Cârligele Git sunt o caracteristică încorporată, ceea ce înseamnă că putem să le accesăm și să începem să le folosim atâta timp cât un depozit git este inițializat. Să aruncăm o privire mai detaliată ce înseamnă asta încercând să le stabilim.

Folosind terminalul preferat, creați un nou depozit git.

 mkdir my-new-repository && cd my-new-repository git init ls -la

Veți observa că tocmai a fost creat un nou director ascuns. Acest folder .git este folosit de la git pentru stocarea informațiilor legate de depozit, cum ar fi hash-uri pentru controlul versiunilor, informații despre comiteri, adrese de depozit la distanță și așa mai departe. Acesta este, de asemenea, folderul în care locuiesc de fapt hooks pentru git .git/hooks . Puteți găsi câteva exemple de scripturi pre-populate create automat în timpul inițializării. Acestea sunt de fapt scripturile care vor fi declanșate după anumite acțiuni.

 ls .git/hooks

Câteva dintre mostrele pe care le puteți găsi sunt:

• pre-commit.sample : invocat chiar înainte de a face commit.
• commit-msg.sample : editați fișierul mesaj în loc.
• post-receive.sample : invocat după actualizarea depozitului de la distanță.

Sub capotă

Acum că știm unde putem găsi cârlige, să facem un pas înapoi pentru a înțelege cum funcționează ele de fapt.

Git hooks sunt bazate pe evenimente, așa că atâta timp cât executăm o comandă git în fluxul de dezvoltare, git va verifica folderele hooks pentru a afla dacă există un script asociat de rulat. Unele dintre aceste scripturi vor rula înainte sau după aceste acțiuni ale fluxului de dezvoltare.

Un exemplu bun pe care să îl parcurgem și să înțelegem mai precis fluxul în care se declanșează cârligele este fluxul de lucru de comitere, care este un caz de utilizare destul de familiar.

Ori de câte ori efectuăm modificări la baza noastră de cod, unele dintre aceste cârlige asociate sunt declanșate în următoarea ordine:

1. pre-commit : inspectează instantaneul care urmează să fie comis și verifică ce urmează să fie comis.
2. prepare-commit-msg : vă permite să editați mesajul implicit înainte ca autorul comitării să-l vadă.
3. commit-msg : setează mesajul de comitere la un șablon.
4. post-commit : execută o acțiune imediat după finalizarea comitării și trimite o notificare, de exemplu.

În depozitul de mai sus, să încercăm acum să adăugăm câteva scripturi personalizate pre- și post-commit pentru a vizualiza în continuare modul în care funcționează de fapt cârligele git.

 nano .git/hooks/pre-commit

Adăugați următorul fragment:

 #!/bin/sh echo Changes are about to be committed

Asigurați-vă că scripturile noastre sunt executabile:

 chmod +x .git/hooks/pre-commit

Repetați procesul de mai sus pentru scriptul post-commit :

 nano .git/hooks/post-commit

 #!/bin/sh echo Changes have been committed

 chmod +x .git/hooks/post-commit

Acum putem adăuga un nou fișier nano index.html cu un mic fragment HTML doar în scopuri demonstrative (nu este nevoie să anunțăm validatorii HTML despre acest lucru).

 <h1>Hello world from our new repository!</h1>

Vom adăuga modificările în baza noastră de cod prin staging și apoi vom efectua acest lucru:

 git add . git commit

După ce comiterea a fost procesată cu succes, putem vedea următoarea ieșire a celor două scripturi adăugate mai sus:

 Changes are about to be committed Changes have been committed

După cum era de așteptat, git a declanșat cârlige în fluxul de comitere. Scripturile pre-commit și post-commit care au fost adăugate rulează și vor fi executate în secvența corectă (pe baza ordinii pe care am menționat-o mai devreme).

Aceasta a fost o demonstrație simplă pentru a înțelege cum funcționează scripturile de flux de lucru de comitere și cum sunt executate. Pentru mai multe detalii despre acest flux de lucru, puteți citi mai multe în documentație.

În exemplul de mai sus, am ales să scriem aceste două scripturi în bash, dar adevărul este că git acceptă hook-uri care pot fi scrise în orice limbaj de scripting dorim. Ruby, Python sau JavaScript sunt alternative excelente, atâta timp cât setăm shebang-ul corect la prima linie a scriptului nostru executabil.

De exemplu, putem rescrie cârligul pre-commit ca un script Node.js, ca mai jos:

 #!/usr/bin/env node console.log("Changes are about to be commited")

Cârlige locale și de la distanță

Cârligele sunt separate între local și la distanță (sau client și server). În timp ce hook-urile locale rulează înainte sau după acțiuni specifice în depozitul local, hook-urile la distanță rulează înainte sau după push-uri către server. Cele locale nu pot fi folosite pentru aplicarea politicilor, deoarece natura lor permite dezvoltatorilor să le modifice cu ușurință. Ele sunt utilizate în principal pentru a respecta anumite linii directoare specifice pe care dorim să le aplicăm în cadrul unei echipe. În cazul în care dorim să devenim mai stricti și să aplicăm unele politici pentru depozitul nostru, locuim în cârlige la distanță.

Cârlige locale

• pre-commit
• prepare-commit-msg
• commit-msg
• post-commit
• applypatch-msg
• pre-applypatch
• post-applypatch
• pre-rebase
• post-rewrite
• post-checkout
• post-merge
• pre-push

Cârlige de la distanță

• pre-receive
• update
• post-receive

Cârlige de partajare

Git hooks se referă la partajarea lor în cadrul echipei. Acesta este principalul motiv pentru care există: promovarea unei colaborări mai bune în echipă, automatizarea proceselor dăunătoare și permițându-ne să ne concentrăm doar asupra părților importante ale bazei de cod.

După cum sa menționat anterior, .git/hooks este folderul care găzduiește hook-urile noastre personalizate, dar acest lucru nu este cu adevărat util atunci când trebuie să partajăm aceste scripturi în echipă, deoarece acest folder nu este urmărit de git.

O abordare bună pentru a rezolva acest lucru este adăugarea tuturor cârligelor noastre personalizate într-un folder separat în depozitul nostru. De exemplu, putem adăuga un folder .githooks și salva acolo scripturile executabile. Apoi, la inițializarea proiectului, putem fie să copiam în mod explicit, fie să le punem în legătură simbolică aceste scripturi la folderul original pentru a ne păstra hook- .git/hooks .

 find .git/hooks -type l -exec rm {} \\; find .githooks -type f -exec ln -sf ../../{} .git/hooks/ \\;

În mod alternativ, dacă utilizați cea mai recentă versiune git (vorbind de 2.9 și mai sus), putem configura direct calea git hooks către folderul nostru personalizat:

 git config core.hooksPath .githooks

Git Hooks Made Easy (Un caz de utilizare JavaScript Codebase)

Există instrumente care ne ajută să integrăm în continuare git hook-urile la nevoile bazei noastre de cod. În special pentru bazele de cod JavaScript, există Husky cu care putem personaliza cu ușurință acțiunile pe evenimentele git prin configurare.

De exemplu, ne putem lăsa cu ușurință codul sau să rulăm unele teste în evenimentul pre-commit și să trecem la comit în funcție de faptul că liningul, testarea sau ambele au succes sau nu.

Acest lucru poate fi realizat prin extinderea configurației package.json pur și simplu ca:

 { "scripts": { "test": "echo Running tests" }, "devDependencies": { "eslint": "5.16.0", }, "husky": { "hooks": { "pre-commit": "eslint . && npm test", } } }

Concluzie

În acest articol, am aflat că diferite acțiuni întreprinse într-un depozit git pot declanșa opțional rularea scripturilor personalizate. Aceste scripturi pot fi sub controlul dezvoltatorului local sau gestionate mai central pentru o echipă sau un proiect de la distanță. Am mai învățat că scripturile sunt adesea scrise într-un script shell precum bash, dar pot folosi aproape orice limbaj de scripting, chiar și JavaScript.

Cârligele Git pot fi o parte foarte puternică a unui flux de lucru bine conceput și te-aș încuraja să le încerci și să vezi ce poți face pentru propriile proiecte.