Hvordan Git bedste praksis sparede mig timer med omarbejdning

For nylig arbejdede jeg på opgaven med at opgradere et certifikat til et NodeJS-program. Dette blev sidst rørt for to år siden for en funktionforbedring. Ethvert live problem, der rejses til denne app, kræver øjeblikkelig opmærksomhed, selvom appen kun er blevet brugt internt.

Appen er gammel. Core-NodeJS-Infra-moduler er ikke blevet opdateret i mere end to år. Downstream-tjenester afskrives. Den måde, vi kalder downstream-tjenester på, ændres. Den stramme frist er et kirsebær på kagen. Jeg vidste, at det skulle være en rutsjebane.

Jeg brugte tre dage på at få appen kørt.

Infra-moduler er opdateret? Kontrollere.

Downstream-tjenester fungerer fint? Kontrollere.

UI-strømme fungerer fint? Kontrollere.

Et af vores teammedlemmer havde rørt appen for en opgradering for over et år siden. Han påpegede, at repoen, hvorfra jeg gaffelede, i sig selv var en gaffelrepo. Nogle andre hold havde arbejdet med den repo, og så arbejdede vores team på den originale repo fra det tidspunkt og fremad - men mit teammedlem ved ikke fra hvilket punkt og frem. Så det var lidt af et rod!

Vi har et "ejerskab" værktøj, der viser den korrekte repo, og det "løj" for mig. Så situationen var sådan:

Forkception

Ja, det var Forkception! WTF og FML var de to første tanker, der kom ud af min mund. Jeg skulle have arbejdet med live repoen, men i stedet arbejdede jeg på en gaffel, der var uaktuel. Hvor dum af mig!

Første tanke - mine tre arbejdsdage er spildt, og jeg er nødt til at begynde nyt.

Anden tanke? Lad mig spørge min gamle ven Git. Han har hjulpet mig i meget lang tid.

Mig - “Hey git? Jeg er i dybe problemer, og jeg har brug for din hjælp til at løse dette problem. ”

Git - “Hej! Ok, så vi er nødt til at starte fra, hvad der er i live først. Opret en ny gren kaldet opgradering, og peg denne filial til live-koden. Du kan bruge en git hard reset til det. ”

Mig - "Ok, det vil jeg."

På dette tidspunkt ser situationen sådan ud.

Brug af Git-funktioner

Git - ”Vi er nødt til at vide, hvad der skiftede mellem udvikling og opgradering. Kan du liste de filer, der er forskellige fra din opgradering og udvikling? Kontroller disse filer individuelt, og find ud af, hvilken slags ændringer der var. ”

Mig - “Cool. Jeg ser tre slags ændringer. Der er en service S1, som jeg har brug for at ringe til på en anden måde. Der er en service S2, som jeg har brug for at ringe ved hjælp af et andet slutpunkt. Der er en service S3, som jeg har brug for at ringe ved hjælp af forskellige parametre. Jeg ser også pakken.json-filen i opgraderingsgrenen har nogle af de pakker, der allerede er opgraderet. Så det er kun et par pakker, der skal ændres. ”

Git - “Fantastisk at du adskiller ændringerne. Vis mig nu Git-loggen for din udviklingsgren. Håber, at du har fulgt nogle grundlæggende Git-fremgangsmåder, for eksempel altid at have en byggbar kode i hvert engagement. Besked om besked skal skildre det, du har ændret. ”

Git log on udvikle gren

Mig - ”Ja, jeg har i alt fire forpligtelser i udviklingsgrenen. En forpligtelse var at gøre projektet opbyggeligt. Der er en for hvert af de tre servicekald. ”

Git - “Perfekt! Det ser ud til, at du har fulgt bedste praksis korrekt. Lad os starte med at stabilisere projektopbygningen ved at gøre package.json opdateret. Kassen til opgraderingsgrenen og lav en duplikat af package.json - package-copy.json. Nu bruger Git erstatte, opgradere / package.json med udvikle / package.json, og køre diffen mellem package.json og package-copy.json. Siden livekoden er nogle af pakkerne allerede ændret og har forskellige versioner, skal du opgradere ved at se på diffen. ”

Gør projektet opbyggeligt

Mig - ”Lad mig prøve det. Ok, det bygger og kører. ”

Git - “Awesome! Lad os nu arbejde med servicekaldene. Jeg ser, at du har en forpligtelse for hver ændring af serviceopkald i udviklingsgrenen. Tid til kirsebærpluk. Vælg fra mindst kompliceret servicekald til det mest komplicerede servicekald. Vælg, fusioner og løs konflikter. Sørg for at kontrollere, om projektet er i byggbar tilstand efter hver kirsebærpluk og før hver forpligtelse. ”

Mig - “S1 færdig. S2 færdig. S3 færdig. Tak, Git ”

Git - ”Du er velkommen. Men det er dig, der har hjulpet dig selv ved at følge Git-tilsagnspraksis og ikke behandle Git som en blot kodelager. ”

Hvad gjorde jeg her?

Forpligtelse relaterede ændringer

Tag en pause et øjeblik og tænk, hvis denne ændring skulle gå i denne forpligtelse. En forpligtelse, der siger, at "ændring: service-s1 endpoints" og har service-s2-ændringer ville bare skabe forvirring.

Gå ikke i arbejde med halvfærdigt arbejde

Vi har ofte hørt "begå tidligt, begå ofte" mantra. I ovenstående eksempel kan du have en engagement for forskellige slutpunkter af den samme service. Dette kaldes pølsefremstilling.

Imidlertid squash jeg personligt mine små forpligtelser ved hjælp af git rebase interaktiv tilstand. Dette hjælper mig til at have en logisk ændring, som kan certificeres, og det hjælper en betroet Committer til også at gennemgå din kode. Dette er meget at foretrække for store projekter.

Test din kode, før du forpligter dig

Vi bør tænke på Git som en statsmaskine, og enhver maskine skal være i bygbar tilstand i enhver tilstand.

Skriv beskeder med god forpligtelse

Dette er en meget vigtig del. Jeg pauser altid et øjeblik og tænker, om jeg - efter tre måneder - vil være i stand til at forstå typen af ​​ændringer i denne forpligtelse ved bare at se på engagement-meddelelsen.

Konklusion

Jeg var i stand til hurtigt at løse rodet. Jeg kunne komme ud af det WTF- og FML-øjeblik, bare fordi jeg fulgte nogle god praksis. De findes af en grund og er som salt i fødevarer - du indser kun deres værdi, når de ikke bruges.

Fejl vil ske før eller senere ubevidst. Men sørg for, at du bevidst følger nogle praksis omkring Git.

Jeg er fan af Git-semantiske engagement-beskeder, som hjælper med at navigere gennem Git-historien. Fordi, lad os være ærlig, kan du ikke forvente, at alle bruger de samme ord til hver begivenhedsmeddelelse. Der kan dog forventes meddelelsestype.

Dette hjælper med at sikre, at dit projekt efter hver forpligtelse kan bygges - hvilket virkelig er nyttigt.

VSCode har sygesupport til Git. Det bliver super let at se konflikterne og løse dem, undertiden med kun et enkelt klik. Se nedenstående eksempel

Referencer

  • Git bedste praksis
  • Super Awesome Version Control Integration i VSCode
  • Git semantiske forpligtelsesmeddelelser
  • Git-tip : Sådan "flettes" specifikke filer fra en anden gren
  • Git-tip : Git - git-cherry-pick-dokumentation
  • Git-tip : Git - git-reset Documentation

Særlig tak til mine venner Saurabh Rajani og Anish Dhargalkar, som hjalp mig med indholdsforfining.