Git Hooks

Publicat: 2022-07-02

Git este un sistem puternic de control al versiunilor pe care abia l-am zgâriat în ultimele noastre postări. Astăzi, ne vom uita la puterea de automatizare pe care ți-o poate oferi Git cu Git Hooks.

Fiecare depozit primește cârlige încorporate atunci când utilizați comanda git init . Când un depozit este inițializat, obțineți un director .git ascuns și în interiorul acestuia se află un director numit hooks care va conține toate hook-urile dvs. Deschideți orice depozit git pe care îl aveți la îndemână și utilizați ls -a pentru a vedea directorul ascuns, apoi deschideți-l în editorul de cod preferat.

Pentru a începe, veți vedea o grămadă de fișiere cu extensii de fișiere .sample . Acestea sunt exact ceea ce spun ei, exemple de scripturi pe care le-ai putea folosi în proiectele tale. Fișierele sunt denumite astfel încât să corespundă cârligului pe care rulează. Deci post-commit.sample rulează pe cârligul post-commit .

Puteți folosi aproape orice limbă pentru a scrie un cârlig. Fișierul este analizat conform notației shebang din partea de sus a fișierului. Dacă vrei să folosești node, ai folosi #! /usr/bindi/env node #! /usr/bindi/env node și fișierul dvs. va fi analizat ca fișier nod.

Înainte de a descoperi ce puteți face cu git hooks, să aruncăm o privire la câteva dintre hook-urile care vă sunt disponibile.

Tipuri de cârlige Git

Commit Workflow Hooks

pre-commit este rulat chiar înainte de a introduce mesajul de commit și poate fi ocolit cu git commit --no-verify .

prepare-commit-msg poate fi folosit pentru a edita mesajul implicit pe care îl vedeți în mesajul de comit. Folosiți-l pentru a oferi instrucțiuni dezvoltatorilor despre ce tip de mesaj de confirmare ar trebui să lase. De asemenea, poate fi folosit pentru a automatiza conținutul unde mesajul este generat automat pentru dvs., cum ar fi fuziuni sau pentru a adăuga automat un număr de problemă la mesajul dvs. de confirmare.

commit-msg poate fi folosit pentru a valida mesajul de commit pentru proiectul dumneavoastră. Poate că nu doriți ca cineva să poată introduce un mesaj de confirmare care spune pur și simplu „tratarea spațiului alb”. Puteți utiliza acest cârlig pentru a detecta prezența cuvintelor spațiu alb și apoi a ieși și a oferi un avertisment utilizatorului că trebuie să aibă un mesaj de confirmare mai bun.

post-commit rulează după toate commit-urile de mai sus. Este cel mai util pentru o notificare că a fost efectuată o comitere.

Cârlige pentru clienți

post-checkout rulează după ce ați executat cu succes o comandă git checkout. Dacă ați avut un set de fișiere mari folosite pe site, dar nu le-ați dorit în controlul sursei, puteți utiliza această comandă pentru a muta fișierele pentru dvs.

pre-push rulează în timpul unei comenzi git push înainte ca orice obiect să fie transferat în depozitul de la distanță.

Cârlige de server

pre-receive rulează atunci când un client a împins codul într-un depozit de la distanță. Acesta poate fi folosit pentru a verifica codul care este împins pentru a vă asigura că îndeplinește criteriile proiectului dumneavoastră înainte de a accepta împingerea.

post-receive rulează după ce depozitul dvs. de la distanță a primit actualizările. Acest lucru ar putea fi folosit pentru a apela un hook web care declanșează un proces de implementare sau pentru a notifica o cameră de chat că a fost primit un commit și este gata de revizuire.

Multe dintre cârligele de mai sus pot fi setate să ruleze numai pe anumite ramuri. Aceasta poate însemna că atunci când utilizați un cârlig post-receive numai atunci când cineva a împins codul în ramura principală care ar trebui să fie gata de implementare. O listă de dezvoltatori ar putea fi notificată să examineze codul și apoi să-l implementeze. În acest fel, veți avea întotdeauna 2 seturi de ochi pe o implementare, ceea ce poate însemna să prindeți greșeli pe care un singur dezvoltator le poate rata cu ușurință.

Am omis unele dintre cârligele disponibile, deoarece nu am văzut niciodată nevoia să le folosesc. Un set de cârlige despre care nu am vorbit sunt cârligele fluxului de lucru prin e-mail. Dacă nu acceptați corecții pentru codul dvs. prin e-mail, atunci probabil că nu veți avea nevoie niciodată de ele. Puteți găsi toate cârligele disponibile în documentație.

În practică, cârligele pe care le-am folosit cel mai mult sunt:

pre-angajare
pre-împingere
commit-msg
pre-primire
post-comitare
post-primire

Acum hai să facem ceva cu aceste cârlige.

Activarea unui plugin WordPress cu WP Cli și Git Hooks

Pentru un proiect client anul acesta am adăugat un magazin și încă mai făceam câteva sarcini pe site-ul principal. Asta însemna că site-ul principal nu avea niciunul dintre pluginurile noastre WooCommerce instalate sau activate. Trebuia să dezvolt magazinul WooCommerce într-o singură ramură și doar odată ce am fost gata să-l împing pe toate live, am vrut să mut WooCommerce pe principal.

Pentru a începe, vom avea nevoie de o nouă sucursală numită magazin. Putem obține acest lucru folosind git checkout -b store . Acest lucru creează o nouă sucursală și o verifică pentru noi. Acum să pregătim cârligul.

Mai întâi trebuie să creăm cârligul post-checkout cu această comandă atingeți .git/hooks/post-checkout .

În continuare trebuie să îl facem executabil. Putem face acest lucru cu comanda chmod din terminalul chmod +x .git/hooks/post-checkout .

Acum deschideți fișierul în editorul dvs. de cod la alegere și copiați codul de mai jos în fișierul post-checkout .

#! /bin/bash

wp plugin activate woocommerce

echo "activated WooCommerce"

wp plugin activate automatewoo

echo "activated AutomateWoo"

Puteți demonstra acest lucru prin schimbarea în orice ramură prin terminal. Ar trebui să vedeți două rânduri care vă spun că WooCommerce și AutomateWoo au fost activate. Știm că funcționează, dar nu este exact ceea ce ne dorim, deoarece va activa pluginurile de fiecare dată când trecem la orice ramură.

Ceea ce ne dorim cu adevărat este să le pornim atunci când ne mutăm în filiala magazinului nostru și apoi să le oprim atunci când suntem în filiala noastră principală. Pentru a face asta, vom avea nevoie de cârlig pentru a detecta ce ramură suntem. Schimbați conținutul post-checkout cu codul de mai jos.

#! /bin/bash

oldrev=$1
newrev=$2

branch_name="(git symbolic-ref HEAD 2>/dev/null)"

if [ "refs/head/store" = "$branch_name" ];then
wp plugin activate woocommerce
echo "activated Woo"

wp plugin activate automatewoo
echo "activated AutomateWoo"
fi

if [ "refs/head/main" = "$branch_name" ];then
wp plugin deactivate woocommerce
echo "deactivated Woo"

wp plugin deactivate automatewoo
echo "deactivated AutomateWoo" fi

Acest cod începe prin alocarea ramurii pe care o verificăm variabilei branch_name . Atunci avem două afirmații if. Primele verifică pentru a vedea dacă ne-am mutat în filiala magazinului. Dacă îl avem, folosește WP CLI pentru a activa WooCommerce și AutomateWoo.

Următoarea instrucțiune if verifică dacă ne aflăm în ramura principală. Dacă suntem, va dezactiva pluginurile cu WP CLI și ne va spune despre asta în terminal.

Controlul fluxurilor de lucru Git cu Git Hooks

Într-o postare anterioară despre Git, am vorbit despre diferite fluxuri de lucru Git. Un caz de utilizare foarte comun pentru hook-uri este oprirea pe oricine să comite cod direct în ramura principală. Puteți folosi un cârlig pentru a vă asigura că tot codul este îmbinat dintr-o ramură diferită în principal.

Începeți prin a redenumi pre-commit.sample în pre-commit și apoi faceți-l executabil așa cum am descris mai sus. Apoi luați codul de mai jos și utilizați-l în fișierul de pre-comitare.

#! /bin/bash

username=$GIT_AUTHOR_NAME branch="$(git symbolic-ref HEAD 2>/dev/null)"

if [ "$branch" = "refs/heads/main" ]; then echo "WHOA that was '"${branch}"' you should not do that. Stop doing silly stuff and create your own branch and merge it." exit 1 # if you remove this it won't block the commit but it will send the message to slack
fi

Acest lucru verifică dacă suntem pe ramura principală și dacă suntem, commit-ul este oprit. Apoi imprimă un memento utilizatorului că nu ar trebui să se angajeze direct în ramura principală.

Amintiți-vă că multe locuri se schimbă în main ca ramură. Proiectele mai vechi pot avea nevoie master aici dacă nu s-au actualizat.

Ai putea chiar să faci un pas mai departe și să folosești cURL pentru a accesa API-ul unei aplicații de chat și apoi să te plângi public că cineva a încercat să se angajeze la main.

Singurele limitări ale git hooks sunt imaginația ta. Le puteți folosi pentru a opri pe cineva să comite dacă în codul lor este prezent un TODO sau pentru a opri spațiile albe la sfârșitul unui fișier.

Dacă aveți o parte din fluxul dvs. de lucru care este o piedică continuă, uitați-vă la cârlige pentru a o automatiza, astfel încât să nu trebuie să vă amintiți.