Când dezvoltatorul modifică formularul de contact sau actualizează tema site-ului, ai nevoie de mai mult decât mesajul „Am terminat”. Este util să știi ce s-a schimbat, de ce și ce versiune a ajuns pe site. Git păstrează istoricul modificărilor de cod și face colaborarea mai ușor de urmărit, chiar dacă tu nu scrii cod.
Nu trebuie să înveți toate comenzile. Contează să înțelegi unde se păstrează codul, cum sunt organizate schimbările și ce verificări ceri înainte de publicare.
Depozitul de cod: locul în care se păstrează proiectul
Git este un sistem de control al versiunilor. El urmărește schimbările fișierelor adăugate într-un proiect și permite compararea stărilor salvate. Proiectul, împreună cu istoricul său, formează depozitul de cod, numit frecvent și repository sau repo.
Dezvoltatorul poate avea o copie locală, iar echipa poate folosi un depozit la distanță, găzduit pe o platformă de colaborare. Acesta nu este același lucru cu spațiul unde rulează site-ul: modificarea codului în depozit nu înseamnă automat publicarea lui.
De exemplu, pentru un site WordPress, depozitul poate conține tema personalizată și extensiile dezvoltate pentru firmă, nu neapărat toate fișierele instalării. Cere o explicație clară despre ce intră în proiect și ce rămâne în afara lui.
- Păstrează depozitul într-un cont sau într-o organizație controlată de firmă.
- Primește acces prin propriul cont, nu prin parola dezvoltatorului.
- Activează autentificarea în doi pași, dacă platforma o oferă.
- Stabilește cine poate invita colaboratori și cine poate publica modificări.
Un depozit privat limitează accesul la persoanele autorizate, dar nu devine astfel un loc potrivit pentru parole.
Commiturile explică ce s-a schimbat și de ce
În versionarea cu Git, un commit este un punct salvat în istoricul proiectului. Are un identificator, un autor declarat, o dată și un mesaj. Împreună cu diferențele dintre fișiere, aceste informații te ajută să urmărești o intervenție. Autorul declarat nu este însă, singur, o dovadă verificată a identității persoanei.
Un mesaj precum „Corectează validarea adresei de e-mail în formularul de ofertă” este mai util decât „Modificări”. Cere ca fiecare commit să grupeze schimbări legate între ele, astfel încât o corecție mică să nu fie amestecată cu refacerea întregii pagini principale.
O versiune pregătită pentru publicare poate primi o etichetă, de exemplu „v1.2.0”. Eticheta indică un punct din istoric; nu certifică automat faptul că proiectul a fost testat. Numerotarea trebuie explicată și folosită consecvent.
Pentru tine, întrebarea utilă este: „Ce identificator sau ce etichetă corespunde versiunii publicate acum?”. Astfel, o sesizare precum „Formularul nu mai trimite mesaje după actualizarea de ieri” poate fi legată de o schimbare concretă, nu doar de o dată aproximativă.
Ramurile de lucru separă dezvoltarea de publicare
O ramură de lucru permite dezvoltarea unor modificări separat de linia principală a proiectului. De exemplu, dezvoltatorul poate lucra la o pagină de servicii pe ramura „pagina-servicii”, în timp ce ramura principală, numită adesea „main”, păstrează codul aprobat.
Ramura nu este un site separat. Pentru a vedea rezultatul în browser, codul trebuie instalat într-un mediu de testare. Acesta trebuie protejat corespunzător, mai ales dacă folosește date copiate din site-ul real.
- Descrii cerința și criteriile de acceptare: „Formularul afișează confirmarea și trimite mesajul la adresa stabilită”.
- Dezvoltatorul lucrează pe o ramură dedicată.
- Deschide o cerere de integrare, numită frecvent pull request sau merge request, cu explicații și verificări.
- Verifici rezultatul în mediul de testare și comunici aprobarea sau observațiile.
- Modificarea este integrată și publicată conform procedurii agreate.
Colaborarea cu dezvoltatorul devine mai clară dacă aprobi un rezultat verificabil, nu doar o listă de fișiere. Stabilește și cine rezolvă eventualele conflicte dintre modificări; acestea necesită analiză, nu acceptare automată.
Fișierele confidențiale nu au loc în istoric
În depozit nu trebuie introduse parole, chei private, tokenuri de acces, date de conectare la baza de date sau exporturi cu informații despre clienți. Regula se aplică și depozitelor private. Copiile locale și accesul colaboratorilor pot extinde expunerea.
Un fișier numit „.gitignore” poate exclude anumite fișiere neurmărite de la adăugarea obișnuită în Git. De exemplu, dezvoltatorul poate exclude fișierul „.env”, exporturile bazei de date, arhivele și jurnalele care conțin date sensibile. Un model precum „.env.example” poate documenta setările necesare, folosind doar valori fictive.
Important: adăugarea unei reguli nu elimină automat un fișier deja urmărit și nici copiile sale din istoricul anterior. Dacă o parolă a fost inclusă într-un commit, ștergerea ei din ultima versiune nu este suficientă.
- Revocă sau schimbă imediat credențialele expuse.
- Cere evaluarea accesului și a posibilelor consecințe.
- Stabilește cu dezvoltatorul dacă trebuie curățat istoricul și coordonate copiile existente.
- Verifică și fișierele accesibile public pe server, inclusiv directorul intern Git, numit „.git”.
Directorul Git nu trebuie să poată fi descărcat de vizitatori. Ideal, publicarea livrează doar fișierele necesare rulării site-ului.
Istoricul codului și copiile de siguranță au roluri diferite
Git păstrează fișierele urmărite, nu starea completă a site-ului. La un magazin online, comenzile recente se află de obicei în baza de date. La un site WordPress, imaginile încărcate și multe setări pot lipsi din depozitul de cod.
O strategie de recuperare trebuie să acopere baza de date, fișierele încărcate, configurația necesară și celelalte componente ale proiectului. Frecvența copiilor, perioada de păstrare, locația și responsabilul trebuie stabilite explicit. Verifică recuperarea într-un mediu separat, nu doar existența arhivelor.
De exemplu, revenirea la codul de dinaintea unei actualizări nu reface automat o structură de bază de date modificată. Invers, restaurarea unei baze de date mai vechi poate elimina comenzile primite între timp. Cere un plan înainte de intervențiile care schimbă datele.
Dacă pregătești infrastructura proiectului, poți lua în calcul serviciile GazduireOnline.ro de găzduire web sau găzduire WordPress, în funcție de platformă. Discută separat cerințele pentru testare, publicare și recuperare, ca să alegi o configurație potrivită.
Ce stabilești la următoarea discuție cu dezvoltatorul
Transformă aceste idei într-o procedură scurtă, accesibilă firmei. Pentru următoarea schimbare, de exemplu înlocuirea formularului de ofertă, cere traseul complet de la cerință până la verificarea după publicare.
- Unde este depozitul și cine controlează accesul?
- Ce fișiere sunt urmărite și unde se păstrează celelalte componente?
- Cum identifici versiunea publicată și cine o aprobă?
- Unde testezi și ce verificări faci după lansare?
- Cum se face recuperarea dacă schimbarea afectează și baza de date?
- Ce accesuri și instrucțiuni primești la încheierea colaborării?
Poți formula cererea simplu: „Te rog să legăm fiecare publicare de un commit sau de o etichetă și să notăm verificările efectuate”. Nu ai nevoie să controlezi fiecare linie de cod. Ai nevoie de acces, explicații și un proces repetabil, în care istoricul schimbărilor și recuperarea site-ului sunt tratate separat.
