Hvordan Git beste praksis sparte meg timer med omarbeidelse

Nylig jobbet jeg med oppgaven med å oppgradere et sertifikat for en NodeJS-applikasjon. Dette ble sist berørt for to år siden for en funksjonsforbedring. Ethvert live problem som tas opp til denne appen vil kreve øyeblikkelig oppmerksomhet, selv om appen bare har blitt brukt internt.

Appen er gammel. Core-NodeJS-Infra-moduler er ikke oppdatert på mer enn to år. Nedstrøms tjenester er avskrevet. Måten vi kaller nedstrøms tjenester endres på. Den stramme fristen er et kirsebær på kaken. Jeg visste at det skulle bli en rutsjebane.

Jeg brukte tre dager på å få appen i gang.

Infrarødmoduler er oppdatert? Kryss av.

Nedstrøms tjenester fungerer bra? Kryss av.

UI-strømmer fungerer bra? Kryss av.

Et av våre teammedlemmer hadde berørt appen for en oppgradering for over ett år siden. Han påpekte at repoen derfra jeg gaflet, i seg selv var en gaffelrepo. Noen andre team hadde jobbet med den repoen, og så jobbet teamet vårt med den originale repoen fra det tidspunktet - men teammedlemmet mitt vet ikke fra hvilket punkt og framover. Så det var litt rot!

Vi har et "eierforhold" -verktøy som viser riktig repo og det "løy" for meg. Så situasjonen var slik:

Forkception

Ja, det var Forkception! WTF og FML var de to første tankene som kom ut av munnen min. Jeg skulle ha jobbet med live-repoen, men i stedet jobbet jeg på en gaffel som var foreldet. Hvor dum av meg!

Først tenkt - de tre dagene mine i jobben er bortkastet, og jeg trenger å begynne på nytt.

Andre tanke? La meg spørre min gamle venn Git. Han har hjulpet meg veldig lenge.

Meg - “Hei git? Jeg har store problemer og trenger din hjelp til å løse dette problemet. "

Git - “Hei! OK, så vi må starte fra hva som er i live først. Opprett en ny gren kalt oppgradering, og pek den grenen til live-koden. Du kan bruke en git hard reset for det. ”

Meg - “Ok, det vil jeg.”

På dette tidspunktet ser situasjonen slik ut.

Bruke Git-funksjoner

Git - “Vi trenger å vite hva som endret mellom utvikling og oppgradering. Kan du liste ut filene som er forskjellige mellom oppgraderingen og utviklingen? Sjekk filene individuelt, og finn ut hva slags endringer det var. ”

Meg - “kult. Jeg ser tre slags endringer. Det er en tjeneste S1 som jeg trenger å ringe på en annen måte. Det er en tjeneste S2 som jeg trenger å ringe ved å bruke et annet endepunkt. Det er en tjeneste S3 som jeg trenger å ringe ved å bruke forskjellige parametere. Jeg ser også pakken.json-filen i oppgraderingsgrenen har noen av pakkene som allerede er oppgradert. Så bare noen få pakker trenger å endres. "

Git - “Fantastisk at du adskiller endringene. Vis meg nå Git-loggen til din utviklingsgren. Håper du har fulgt noen grunnleggende Git-praksiser, for eksempel alltid å ha byggbar kode i hver forpliktelse. Forpliktelsesmeldingen skal skildre det du har endret. "

Git logge på utvikle gren

Meg - “Ja, jeg har totalt fire forpliktelser i utviklingsgrenen. En forpliktelse var å gjøre prosjektet byggbart. Det er en for hver av de tre tjenestesamtalene. ”

Git - “Perfekt! Det virker som om du har fulgt beste praksis på riktig måte. La oss starte med å stabilisere prosjektbyggingen ved å gjøre package.json oppdatert. Kassa til oppgraderingsgrenen og lag en duplikat av package.json - package-copy.json. Nå bruker du Git erstatte, oppgradere / package.json med utvikle / package.json, og kjør diffen mellom package.json og package-copy.json. Siden livekoden har noen av pakkene endret seg allerede, og har forskjellige versjoner, må du oppgradere ved å se på diff. "

Gjør prosjektet byggbart

Meg - “La meg prøve det. OK, det bygger og kjører. ”

Git - “Kjempebra! La oss nå jobbe med tjenesteanropene. Jeg ser at du har en forpliktelse for hver endring av tjenesteanrop i utviklingsgrenen. På tide å kirsebær plukke. Velg fra minst kompliserte serviceanrop til det mest kompliserte serviceanropet. Velg, flett og løp konflikter. Sørg for å sjekke om prosjektet er i byggbar tilstand etter hver kirsebærplukk og før hver forpliktelse. ”

Meg - “S1 gjort. S2 gjort. S3 gjort. Takk, Git ”

Git - “Du er velkommen. Men det er du som har hjulpet deg selv, ved å følge Git-forpliktelsespraksis, og ikke behandle Git som bare kodelager. "

Hva gjorde jeg her?

Foreta relaterte endringer

Ta en pause et øyeblikk og tenk om denne endringen skulle gå i denne forpliktelsen. En forpliktelse som sier at “endring: service-s1 endpoints” og har service-s2 endringer ville bare skapt forvirring.

Ikke begi halvarbeid

Vi har ofte hørt "begå tidlig, begå ofte" mantra. I eksemplet over kan du ha en forpliktelse for forskjellige sluttpunkter av den samme tjenesten. Dette kalles Pølsemaking.

Imidlertid squash jeg personlig mine små forpliktelser ved hjelp av git rebase interaktiv modus. Dette hjelper meg til å ha en logisk endring, som kan sertifiseres, og det hjelper en betrodd committer til å gjennomgå koden din også. Dette er mye å foretrekke for store prosjekter.

Test koden før du forplikter deg

Vi bør tenke på Git som en statlig maskin, og enhver maskin skal være i byggbar tilstand når som helst.

Skriv gode engasjementsmeldinger

Dette er en veldig viktig del. Jeg pauser alltid et øyeblikk og tenker på om jeg vil være i stand til å forstå - etter tre måneder - hva slags endring i denne forpliktelsen er ved bare å se på forpliktelsesmeldingen.

Konklusjon

Jeg klarte raskt å løse rotet. Jeg kunne komme ut av det WTF- og FML-øyeblikket bare fordi jeg fulgte noen god praksis. De eksisterer av en grunn og er som salt i maten - du innser bare verdien deres når de ikke brukes.

Feil vil skje før eller senere, ubevisst. Men pass på at du bevisst følger noen praksis rundt Git.

Jeg er fan av Git-semantiske engasjementsmeldinger, som hjelper deg med å navigere gjennom Git-historien. Fordi, la oss være ærlige, kan du ikke forvente at alle bruker de samme ordene for hver engasjementsmelding. Meldingstype kan imidlertid forventes.

Dette hjelper deg med å sikre at prosjektet ditt etter hvert engasjement kan bygges - noe som virkelig er nyttig.

VSCode har syk støtte for Git. Det blir superenkelt å se konfliktene og løse dem, noen ganger med bare et enkelt klikk. Se eksemplet nedenfor

referanser

  • Git Best Practices
  • Super Awesome Versjon Control Integrasjon i VSCode
  • Git semantiske forpliktelsesmeldinger
  • Git-tips : Hvordan "slå sammen" bestemte filer fra en annen gren
  • Git-tips : Git - git-cherry-pick-dokumentasjon
  • Git-tips : Git - git-reset Documentation

Spesiell takk til vennene mine Saurabh Rajani og Anish Dhargalkar som hjalp meg med foredling av innhold.