Hoe Git best practices mij uren werk hebben bespaard

Onlangs werkte ik aan de taak om een ​​certificaat voor een NodeJS-toepassing te upgraden. Dit werd twee jaar geleden voor het laatst aangeraakt voor een verbetering van de functies. Elk live probleem dat aan deze app wordt voorgelegd, vereist onmiddellijke aandacht, hoewel de app alleen intern is gebruikt.

De app is oud. Core-NodeJS-Infra-modules zijn al meer dan twee jaar niet bijgewerkt. Downstream-services zijn verouderd. De manier waarop we downstream-services noemen, is gewijzigd. De strakke deadline is een kers op de taart. Ik wist dat het een achtbaanrit zou worden.

Ik heb drie dagen besteed aan het draaien van de app.

Infra-modules zijn bijgewerkt? Controleren.

Downstream-services werken prima? Controleren.

UI stromen werken goed? Controleren.

Een van onze teamleden had de app ruim een ​​jaar geleden aangeraakt voor een upgrade. Hij wees erop dat de repo van waar ik me vertakte zelf een gevorkte repo was. Een ander team had aan die repo gewerkt en ons team werkte vanaf dat moment aan de oorspronkelijke repo - maar mijn teamlid weet niet vanaf welk punt. Dus het was een beetje een puinhoop!

We hebben een 'Ownership'-tool die de juiste repo toont en die tegen me' heeft gelogen '. Dus de situatie was als volgt:

Forkception

Ja, het was Forkception! WTF en FML waren de eerste twee gedachten die uit mijn mond kwamen. Ik had aan de live repo moeten werken, maar in plaats daarvan werkte ik aan een vork die oud was. Wat dom van mij!

Eerste gedachte - mijn drie dagen werk zijn verspild en ik moet opnieuw beginnen.

Tweede gedachte? Laat me het mijn oude vriend Git vragen. Hij helpt me al heel lang.

Me - "Hey Git? Ik zit diep in de problemen en ik heb je hulp nodig om dit probleem op te lossen. "

Git - "Hé! Oké, dus we moeten eerst beginnen met wat er ook live is. Maak een nieuwe branch genaamd upgrade en wijs die branch naar de live code. Je kunt daarvoor een git hard reset gebruiken. '

Ik - "Ok, dat zal ik doen."

Op dit moment ziet de situatie er als volgt uit.

Git-functies gebruiken

Git - “We moeten weten wat er is veranderd tussen ontwikkelen en upgraden. Kun je de bestanden vermelden die verschillen tussen je upgrade en ontwikkeling? Controleer die bestanden afzonderlijk en zoek uit wat voor soort wijzigingen er waren. '

Ik - "Cool. Ik zie drie soorten veranderingen. Er is een service S1 die ik op een andere manier moet bellen. Er is een service S2 die ik moet bellen met een ander eindpunt. Er is een service S3 die ik moet bellen met behulp van verschillende parameters. Ik zie ook dat het bestand package.json in de upgradetak enkele van de pakketten al heeft geüpgraded. Er hoeven dus maar een paar pakketten te worden gewijzigd. ”

Git - “Geweldig dat je de veranderingen hebt gescheiden. Laat me nu het Git-logboek zien van je develop branch. Ik hoop dat je een aantal basis Git-werkwijzen hebt gevolgd, bijvoorbeeld altijd met bouwbare code in elke commit. Het commit-bericht moet weergeven wat je hebt gewijzigd. ”

Git log in ontwikkel branch

Me - “Ja, ik heb in totaal vier commits in de develop-branche. Eén toezegging was om het project te bouwen. Er is één voor elk van de drie serviceaanvragen. ”

Git - “Perfect! Het lijkt erop dat u best practices correct hebt gevolgd. Laten we beginnen met het stabiliseren van de projectopbouw door package.json up-to-date te maken. Afrekenen naar de upgrade branch en maak een duplicaat van package.json - package-copy.json. Gebruik nu Git vervangen, upgrade / package.json met develop / package.json en voer het verschil uit tussen package.json en package-copy.json. Sinds de live code zijn sommige pakketten al gewijzigd en hebben verschillende versies, je moet upgraden door naar de diff te kijken. ”

Het project bouwbaar maken

Me - “Laat me dat proberen. Oké, het is aan het bouwen en rennen. ”

Git - “Geweldig! Laten we nu aan de serviceaanvragen werken. Ik zie dat je één commit hebt voor elke service-call verandering in de develop branch. Tijd om kersen te plukken. Kies uit de minst gecompliceerde serviceaanvraag tot de meest gecompliceerde serviceaanvraag. Conflicten kiezen, samenvoegen en oplossen. Controleer na elke cherry-pick en voor elke commit of het project in bouwbare staat is. "

Me - “S1 klaar. S2 klaar. S3 klaar. Bedankt, Git ”

Git - "Graag gedaan. Maar jij bent het die jezelf hebt geholpen, door Git commit-praktijken te volgen en Git niet als louter een code-opslag te behandelen. "

Wat heb ik hier gedaan?

Commit gerelateerde wijzigingen

Neem even een pauze en bedenk of deze verandering in deze commit zou moeten doorgaan. Een commit die zegt dat "verandering: service-s1 eindpunten" en wijzigingen in service-s2 heeft, zou gewoon verwarring veroorzaken.

Bega niet met half werk

We hebben vaak de mantra 'vroeg begaan, vaak begaan' gehoord. In het bovenstaande voorbeeld kunt u één commit voor verschillende eindpunten van dezelfde service hebben. Dit wordt worst maken genoemd.

Ik squash echter persoonlijk mijn kleine commits met behulp van de interactieve modus git rebase. Dit helpt me om één logische wijziging te hebben, die kan worden gecertificeerd, en het helpt een Trusted Committer ook om uw code te beoordelen. Dit heeft veel de voorkeur voor grootschalige projecten.

Test uw code voordat u begint

We moeten Git beschouwen als een staatsmachine, en elke machine moet in elke staat in bouwbare staat zijn.

Schrijf goede commit-berichten

Dit is een zeer cruciaal onderdeel. Ik pauzeer altijd voor een moment en denk na of ik in staat zal zijn om - na drie maanden - het soort verandering in deze commit te begrijpen door alleen maar naar de commit-boodschap te kijken.

Gevolgtrekking

Ik was in staat om de rommel snel op te lossen. Ik kon uit dat WTF- en FML-moment komen, gewoon omdat ik een aantal goede praktijken volgde. Ze bestaan ​​niet voor niets en zijn als zout in voedsel - je beseft hun waarde alleen als ze niet worden gebruikt.

Fouten zullen vroeg of laat gebeuren, onbewust. Maar zorg ervoor dat je bewust enkele praktijken rond Git volgt.

Ik ben een fan van Git semantische commit-berichten, die helpen om door de Git-geschiedenis te navigeren. Omdat, laten we eerlijk zijn, je niet kunt verwachten dat iedereen dezelfde woorden gebruikt voor elk commit-bericht. Er kan echter een berichttype worden verwacht.

Dit helpt ervoor te zorgen dat, na elke commit, je project kan worden gebouwd - wat echt nuttig is.

VSCode heeft een slechte ondersteuning voor Git. Het wordt supergemakkelijk om de conflicten te zien en op te lossen, soms met slechts een enkele klik. Zie het onderstaande voorbeeld

Referenties

  • Git Best Practices
  • Super Awesome versiebeheer-integratie in VSCode
  • Git Semantic Commit-berichten
  • Git Tip : Hoe specifieke bestanden uit een andere branch te "mergen"
  • Git Tip : Git - git-cherry-pick Documentatie
  • Git Tip : Git - git-reset Documentatie

Speciale dank aan mijn vrienden Saurabh Rajani en Anish Dhargalkar die me hebben geholpen met het verfijnen van de inhoud.