de Hemal Patel

Modul în care cele mai bune practici Git mi-au salvat ore de prelucrare

Recent am lucrat la sarcina de a actualiza un certificat pentru o aplicație NodeJS. Acest lucru a fost atins ultima dată acum doi ani pentru o îmbunătățire a funcției. Orice Trăi problema ridicată acestei aplicații ar necesita o atenție imediată, deși aplicația a fost utilizată doar intern.

Aplicația este veche. Modulele Core-NodeJS-Infra nu au fost actualizate de mai bine de doi ani. Serviciile din aval sunt depreciate. Modul în care apelăm serviciile din aval este schimbat. Termenul limită este o cireșă pe tort. Știam că va fi o plimbare cu roller-coaster.

Am petrecut trei zile punând aplicația în funcțiune.

Infra-module sunt actualizate? Verifica.

Serviciile din aval funcționează bine? Verifica.

Fluxurile de interfață funcționează bine? Verifica.

Unul dintre membrii echipei noastre a atins aplicația pentru o actualizare de peste un an în urmă. El a subliniat că repo-ul de unde am bifurcat era el însuși un repo bifurcat. O altă echipă a lucrat la acea repo, iar apoi echipa noastră a lucrat la repo-ul original începând cu acel moment – dar membrul echipei mele nu știe de la ce punct încoace. Deci a fost un pic de mizerie!

Avem un instrument „Proprietate” care arată repo-ul corect și „m-a mințit”. Deci situația a fost așa:

Cum cele mai bune practici Git mi au salvat ore de
Forkception

Da, a fost Forkception! WTF și FML au fost primele două gânduri care mi-au ieșit din gură. Eu ar trebui să am lucrat la repo live, dar, in schimb, Am lucrat la o furculiță veche. Ce prost de mine!

Primul gând – cele trei zile de muncă ale mele au fost irosite și trebuie să încep din nou.

Ezitare? Lasă-mă să-l întreb pe vechiul meu prieten Git ?. Mă ajută de foarte mult timp.

Cum cele mai bune practici Git mi au salvat ore de

Pe mine – „Hei Git? Am o problemă profundă și am nevoie de ajutorul tău pentru rezolvarea acestei probleme. ”

Git – “Hei! Ok, deci trebuie să începem mai întâi de la orice este în direct. Creați o nouă ramură numită modernizare, și indicați acea ramură către codul live. Puteți utiliza un git hard reset pentru asta.”

Pe mine – „Ok, o voi face”.

În acest moment, situația arată astfel.

1612188909 729 Cum cele mai bune practici Git mi au salvat ore de
Utilizarea funcțiilor Git

Git – „Trebuie să știm ce s-a schimbat între dezvoltare și actualizare. Puteți lista fișierele care diferă între dvs. modernizare și dezvolta? Verificați acele fișiere individual și aflați ce fel de modificări au existat. ”

Pe mine – “Misto. Văd trei feluri de schimbări. Există un serviciu S1 pe care trebuie să-l apelez într-un mod diferit. Există un serviciu S2 pe care trebuie să îl apelez folosind un punct final diferit. Există un serviciu S3 pe care trebuie să îl apelez folosind parametri diferiți. Văd și pachet.json fișier în modernizare sucursala are unele dintre pachetele deja actualizate. Deci, doar câteva pachete trebuie schimbate. ”

Git – „Minunat că ați separat segregările. Acum arată-mi jurnalul Git al tău dezvolta ramură. Sper că ați urmat câteva practici de bază Git, de exemplu, având întotdeauna cod construibil în fiecare commit. Mesajul de confirmare ar trebui să descrie ceea ce ați schimbat. ”

1612188909 627 Cum cele mai bune practici Git mi au salvat ore de
Git log on develop branch

Pe mine – „Da, am în total patru comitere în dezvolta ramură. Un angajament a fost acela de a face proiectul construibil. Există câte unul pentru fiecare dintre cele trei apeluri de service. ”

Git – “Perfect! Se pare că ați urmat în mod corespunzător cele mai bune practici. Să începem prin stabilizarea construcției proiectului actualizând package.json. Checkout la modernizare ramificați și creați un duplicat al package.json – package-copy.json. Acum, folosind Git a inlocui , upgrade / package.json cu develop / package.json și rulați diferența dintre package.json și package-copy.json. Întrucât, codul live a modificat deja unele dintre pachete și are versiuni diferite, va trebui să faceți upgrade examinând diferențele. ”

1612188910 785 Cum cele mai bune practici Git mi au salvat ore de
Realizarea proiectului construibil

Pe mine – „Lasă-mă să încerc asta. Ok, se construiește și funcționează. ”

Git – “Minunat! Acum, să lucrăm la apelurile de serviciu. Văd că aveți un singur commit pentru fiecare schimbare a apelului de serviciu în ramura de dezvoltare. Timp pentru cireș. Alegeți de la apelul de service cel mai puțin complicat până la cel mai complicat apel de service. Alegeți, combinați și rezolvați conflictele. Asigurați-vă că verificați dacă proiectul este în stare construibilă după fiecare cireș-culegător și inainte de fiecare comitere. ”

Pe mine – „S1 terminat. S2 terminat. S3 gata. Mulțumesc, Git ”

Git – “Cu plăcere. Dar tu ești cel care te-ai ajutat, urmând practicile de angajare Git și nu tratând Git ca pe un simplu stocare de coduri ”.

Ce am făcut aici? ?

Faceți o pauză pentru un moment și gândiți-vă dacă această schimbare ar trebui să apară în acest commit. Un commit care spune că „change: service-s1 endpoints” și are modificări service-s2 ar crea doar confuzie.

Nu vă angajați la jumătate de lucru

Am auzit adesea mantra „comite devreme, comite des”. În exemplul de mai sus, puteți avea un singur commit pentru diferite puncte finale ale aceluiași serviciu. Aceasta se numește Fabricarea mezelurilor.

Cu toate acestea, personal îmi împiedic micile angajamente folosind modul interactiv git rebase. Acest lucru mă ajută să am o schimbare logică, care poate fi certificată, și ajută un comisionar de încredere să vă revizuiască și codul. Acest lucru este mult mai preferabil pentru proiectele de anvergură.

Testați-vă codul înainte de a vă angaja

Ar trebui să ne gândim la Git ca la o mașină de stat și orice mașină ar trebui să fie în stare construibilă în orice stare.

Scrieți mesaje de angajament bune

Aceasta este o parte crucială. Mă opresc întotdeauna pentru o clipă și mă gândesc dacă voi putea înțelege – după trei luni – tipul de schimbare în acest comitet, doar uitându-mă la mesajul de comitere.

Concluzie

Am putut rezolva rapid mizeria. Aș putea ieși din acel moment WTF și FML doar pentru că am urmat câteva bune practici. Există dintr-un motiv și sunt ca sarea din alimente – îți dai seama de valoarea lor doar atunci când nu sunt folosite.

Greșelile se vor întâmpla mai devreme sau mai târziu, inconștient. Dar asigurați-vă că urmați în mod conștient câteva practici în jurul Git.

Sunt un fan al Mesaje de comitere semantice Git, care ajută la navigarea prin istoria Git. Pentru că, să fim sinceri, nu vă puteți aștepta ca toată lumea să folosească aceleași cuvinte pentru fiecare mesaj de comitere. In orice caz, tip mesaj poate fi de așteptat.

Acest lucru vă asigură că, după fiecare comitere, proiectul dvs. poate fi construit – ceea ce este foarte util.

VSCode are suport bolnav pentru Git. Devine foarte ușor să vezi conflictele și să le rezolvi, uneori cu un singur clic. Vedeți exemplul de mai jos?

1612188910 839 Cum cele mai bune practici Git mi au salvat ore de

Referințe

Mulțumiri speciale prietenilor mei Saurabh Rajani și Anish Dhargalkar care m-a ajutat cu rafinarea conținutului.