A Git bevált gyakorlatai hogyan spóroltak meg több órás átdolgozást

A közelmúltban azon dolgoztam, hogy frissítsek egy NodeJS alkalmazás tanúsítványát. Ezt utoljára két éve érintették meg egy funkcióbővítés céljából. Bármely , az alkalmazással kapcsolatban felmerülő élő probléma azonnali figyelmet igényel, bár az alkalmazást csak belsőleg használták.

Az alkalmazás régi. A Core-NodeJS-Infra modulokat több mint két éve nem frissítették. A downstream szolgáltatások elavultak. Megváltozik a downstream szolgáltatások hívásának módja. A szűk határidő cseresznye a tortán. Tudtam, hogy hullámvasút lesz.

Három napot töltöttem az alkalmazás futtatásával.

Inframodulok frissülnek? Jelölje be.

A downstream szolgáltatások jól működnek? Jelölje be.

A felhasználói felület áramlása rendben működik? Jelölje be.

Csapatunk egyik tagja több mint egy évvel ezelőtt megérintette az alkalmazást egy frissítés céljából. Rámutatott, hogy a repó, ahonnan elágaztam, maga is villás repó volt. Néhány másik csapat dolgozott ezen a repón, majd a csapatunk ettől a ponttól kezdve az eredeti repón dolgozott - de a csapattagom nem tudja, hogy melyik ponttól kezdve. Szóval egy kis rendetlenség volt!

Van egy „Tulajdonosi” eszközünk, amely megmutatja a helyes repót, és nekem „hazudott”. Tehát a helyzet ilyen volt:

Igen, Forkception volt! A WTF és az FML volt az első két gondolat, ami kijött a számból. Dolgozni kellett volna az élő repón, de ehelyett egy elaggott villán dolgoztam. Milyen hülye belőlem!

Első gondolat - a három napos munkám elvesztegetett, és frissen kell kezdenem.

Második gondolat? Hadd kérdezzem meg régi barátomat, Git ?. Nagyon régóta segít nekem.

Én - „Hé Git? Mély bajban vagyok, és segítségedre van szükségem a probléma megoldásában.

Git - „Hé! Oké, tehát előbb abból kell kiindulnunk, ami élőben van. Hozzon létre egy új ágat, úgynevezett frissítést , és mutassa azt az ágat az élő kódra. Ehhez használhat egy git hard reset-et. ”

Én - "Oké, megteszem."

Ezen a ponton a helyzet így néz ki.

Git - „Tudnunk kell, mi változott a fejlesztés és a frissítés között. Ki tudná sorolni azokat a fájlokat, amelyek különböznek a frissítés és a fejlesztés között ? Ellenőrizze ezeket a fájlokat külön-külön, és derítse ki, hogy milyen változások történtek. "

Én - „Klassz. Háromféle változást látok. Van egy S1 szolgáltatás, amelyet más módon kell felhívnom. Van egy S2 szolgáltatás, amelyet egy másik végpont használatával kell meghívnom. Van egy S3 szolgáltatás, amelyet különböző paraméterekkel kell hívnom. Azt is látom , hogy a frissítési ágban a package.json fájl néhány csomagot már frissített. Tehát csak néhány csomagot kell megváltoztatni. ”

Git - „Félelmetes, hogy szétválasztottad a változásokat. Most mutasd meg a fejlesztési ágad Git naplóját . Remélem, hogy betartott néhány alapvető Git-gyakorlatot, például mindig rendelkezik beépíthető kóddal minden egyes elkötelezettségben. Az elkötelező üzenetnek azt kell ábrázolnia, amit megváltoztatott.

Én - „Igen, összesen négy elkötelezettségem van a fejlesztési ágban. Az egyik elkötelezettség a projekt építhetővé tétele volt. Mindhárom szervizhíváshoz tartozik egy. ”

Git - „Tökéletes! Úgy tűnik, hogy megfelelően követte a bevált gyakorlatokat. Kezdjük azzal, hogy stabilizáljuk a projekt összeállítását a csomag.json naprakészen tartásával. Jelentkezzen be a frissítési ágba, és készítsen másolatot a package.json - package-copy.json fájlról. Most a Git használatával cserélje le a upgrade / package.json fájlt a develop / package.json fájlra, és futtassa a diff a package.json és a package-copy.json között. Mivel az élő kód néhány csomagját már megváltoztatta, és különböző verziói vannak, akkor a diff megnézésével frissítenie kell. "

Én - „Hadd próbáljam ki. Ok, épül és működik.

Git - „Félelmetes! Most dolgozzunk a szervizhívásokkal. Úgy látom, hogy a fejlesztési ágban minden szolgáltatási hívásváltozásra egy-egy elkötelezettség van. Ideje meggyszedni. Válasszon a legkevésbé bonyolult szervizhívástól a bonyolultabb szervizhívásig. Válassza ki, egyesítse és oldja meg a konfliktusokat. Minden cseresznyés válogatás után és minden elkötelezettség előtt ellenőrizze, hogy a projekt építhető állapotban van -e .

Én - „S1 kész. S2 kész. S3 kész. Köszönöm, Git ”

Git - „Szívesen. De te segítettél magadon azzal, hogy követed a Git elkövetési gyakorlatát, és nem kezeled Git puszta kódtárolóként. "

Mit csináltam itt? ?

Végezze el a kapcsolódó változásokat

Tartson egy kis szünetet egy pillanatra, és gondolkodjon el, hogy ez a változás bekövetkezik-e ebben az elkötelezettségben. Egy olyan kötelezettségvállalás, amely azt mondja, hogy a „változás: szolgáltatás-s1 végpontok” és a szolgáltatás-s2 változások vannak, csak zavart okozna.

Ne végezzen félkész munkát

Gyakran hallottuk a „korán elkövetni, gyakran elkövetni” mantrát. A fenti példában megadhat egy elköteleződést ugyanazon szolgáltatás különböző végpontjaihoz. Ezt hívják Kolbászkészítésnek .

Én azonban személyesen összezúzom a kis elkötelezettségeket a git rebase interaktív mód használatával . Ez segít nekem egy logikai változtatásban, amely igazolható, és segít egy megbízható megbízottnak a kódjának felülvizsgálatában is. Ez sokkal inkább a nagyszabású projektek esetében.

Tesztelje kódját, mielőtt elkötelezi magát

Gitre állami gépként kell gondolnunk, és minden gépnek bármilyen állapotban építhető állapotban kell lennie.

Írjon jó elkötelezettségű üzeneteket

Ez a legfontosabb rész. Mindig szünetet tartok egy pillanatra, és arra gondolok, hogy képes vagyok-e megérteni - három hónap elteltével - az ilyen elkötelezettség változásait, ha csak az elkötelezettség üzenetét nézem.

Következtetés

Sikerült gyorsan megoldanom a rendetlenséget. Kijöhettem abból a WTF és FML pillanatból, csak azért, mert követtem néhány jó gyakorlatot. Okkal léteznek, és olyanok, mint a só az ételekben - értéküket csak akkor veszi észre, ha nem használják őket.

A hibák előbb-utóbb, öntudatlanul történnek. De mindenképpen tudatosan kövesse a Git körüli néhány gyakorlatot.

Rajongok a Git szemantikus elkötelező üzenetekért, amelyek segítenek eligazodni a Git történetében. Mert legyünk őszinték, nem számíthat arra, hogy mindenki ugyanazokat a szavakat használja az egyes elkötelezett üzenetekhez. Ugyanakkor üzenettípusra lehet számítani.

Ez segít megbizonyosodni arról, hogy minden elkötelezettség után elkészülhet a projekt - ami valóban hasznos.

A VSCode beteg támogatást nyújt Git számára. Rendkívül egyszerűvé válik a konfliktusok áttekintése és megoldása, néha egyetlen kattintással. Lásd az alábbi példát?

Hivatkozások

  • Git legjobb gyakorlatok
  • Szuper fantasztikus verziókezelő integráció a VSCode-ban
  • Git Semantic Commit üzenetek
  • Git Tip?: Hogyan egyesítheti az egyes fájlokat egy másik ágból
  • Git Tipp?: Git - git-cherry-pick Dokumentáció
  • Git tipp?: Git - git-reset dokumentáció

Külön köszönet Saurabh Rajani és Anish Dhargalkar barátaimnak, akik segítettek a tartalom finomításában.