Hvordan Git's bedste praksis sparede mig timevis af omarbejdning

For nylig arbejdede jeg på opgaven med at opgradere et certifikat til en NodeJS-applikation. Dette blev sidst rørt for to år siden for en forbedring af funktionen. Ethvert live- spørgsmål, der rejses til denne app, vil kræve øjeblikkelig opmærksomhed, selvom appen kun er brugt internt.

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

Jeg brugte tre dage på at køre appen.

Inframoduler opdateres? Kontrollere.

Downstream-tjenester fungerer fint? Kontrollere.

UI-strømme fungerer fint? Kontrollere.

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

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

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

Første tanke - mine tre dages arbejde er spildt, og jeg skal begynde frisk.

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

Mig - “Hej Git? Jeg har 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 med alt, hvad der er live, først. Opret en ny filialkaldt opgradering , og peg den gren 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.

Git - “Vi har brug for at vide, hvad der ændrede sig mellem udvikling og opgradering. Kan du liste ud af de filer, der adskiller sig mellem 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 skal ringe til på en anden måde. Der er en tjeneste S2, som jeg skal ringe til ved hjælp af et andet slutpunkt. Der er en service S3, som jeg skal ringe til ved hjælp af forskellige parametre. Jeg ser også package.json- filen i opgraderingsgrenen har nogle af pakkerne allerede opgraderet. Så kun få pakker skal ændres. ”

Git - “Awesome at du adskilt ændringerne. Vis mig nu Git-loggen for din udviklingsfilial . Håber du har fulgt nogle grundlæggende Git-fremgangsmåder, for eksempel altid at have koden, der kan bygges, i hver forpligtelse. Forpligtelsesmeddelelsen skal skildre, hvad du har ændret. ”

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

Git - “Perfekt! Det ser ud til, at du har fulgt bedste praksis korrekt. Lad os starte med at stabilisere projektbygningen ved at gøre package.json opdateret. Checkout til opgraderingsgrenen, og lav en kopi af package.json - package-copy.json. Brug nu Git erstat, opgrader / pakke.json med udvikle / pakke.json, og kør forskellen mellem pakke.json og pakke-copy.json. Da live-koden allerede har ændret nogle af pakkerne og har forskellige versioner, skal du opgradere ved at se på diff. ”

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

Git - “Awesome! Lad os nu arbejde på serviceopkaldene. Jeg ser, at du har en forpligtelse for hver ændring af serviceopkald i udviklingsgrenen. Tid til kirsebærpluk. Vælg mellem mindst kompliceret serviceopkald til det mest komplicerede serviceopkald. Vælg, flet og løs konflikter. Sørg for at kontrollere, om projektet er i byggbar stand efter hver kirsebærpluk og inden 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 begå praksis og ikke behandle Git som en simpel kodelagring. ”

Hvad gjorde jeg her? ?

Foretag relaterede ændringer

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

Foretag ikke halvt udført arbejde

Vi har ofte hørt ”begå tidligt, begå ofte” mantraet. I ovenstående eksempel kan du have en forpligtelse til forskellige slutpunkter for den samme tjeneste. Dette kaldes Sausage Making .

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

Test din kode, inden du forpligter dig

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

Skriv meddelelser om god forpligtelse

Dette er en meget vigtig del. Jeg stopper altid et øjeblik og tænker, om jeg - efter tre måneder - kan forstå, hvilken form for ændring i denne forpligtelse ved bare at se på 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 gode fremgangsmåder. De eksisterer af en grund og er som salt i mad - 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 øvelser omkring Git.

Jeg er en fan af Git semantiske meddelelser, der hjælper med at navigere gennem Git-historien. Fordi, lad os være ærlige, kan du ikke forvente, at alle bruger de samme ord til hver begivenhedsmeddelelse. Imidlertid kan meddelelsestype forventes.

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

VSCode har syg støtte til Git. Det bliver super nemt at se konflikterne og løse dem, nogle gange med kun et enkelt klik. Se nedenstående eksempel?

Referencer

  • Git bedste praksis
  • Super Awesome versionskontrolintegration i VSCode
  • Git semantiske forpligtelsesmeddelelser
  • Git Tip?: Hvordan "flettes" specifikke filer fra en anden gren
  • Git Tip?: Git - git-cherry-pick dokumentation
  • Git Tip?: Git - git-reset Dokumentation

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