A Git bevált gyakorlatai órák óta engedtek meg újratöltést

Nemrég dolgoztam egy NodeJS alkalmazáshoz tartozó tanúsítvány frissítésére. Ezt utoljára két évvel ezelőtt megérintették egy szolgáltatás fejlesztése céljából. Az alkalmazáshoz kapcsolódó bármely élő kérdés 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 két éve nem frissítették. A downstream szolgáltatások elavultak. Megváltozott az a mód, ahogyan a downstream szolgáltatásokat hívjuk. 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.

Az infra-modulok frissülnek? Jelölje be.

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

Az UI-áramlások jól működnek? Jelölje be.

Csapatunk egyik tagja megérintette az alkalmazást, hogy frissítsen egy évvel ezelőtt. Hangsúlyozta, hogy a repó, ahonnan forkáltam, maga is egy villás repó. Valami más csapat dolgozott ezen a repo-n, majd a mi csapatunk attól a ponttól kezdve az eredeti repo-n dolgozott - de a csapatom tagja nem tudja, mióta kezdődik. Tehát kicsit zavaros volt!

Van egy „tulajdonjog” eszköz, amely megmutatja a helyes repót, és nekem „hazudott”. Tehát a helyzet így volt:

Forkception

Igen, ez Forkception volt! A WTF és az FML voltak az első két gondolat, amelyek kijöttek a számon. Az élő repo-n kellett volna dolgoznom, ehelyett egy elakadott villán dolgoztam. Milyen hülye vagyok tőlem!

Első gondolat - három napos munkám elpazarolt, és frissnek kell kezdnem.

Második gondolat? Hadd kérdezzem meg régi barátomat, Git-t. Nagyon sokáig segített nekem.

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

Git - „Hé! Rendben, tehát attól kezdve kell kezdenünk, ami élőben van. Hozzon létre egy új fióktelep nevű frissítést, és mutasson arra az élő kódra. Ehhez használhat egy git hard reset-et. ”

Én - "Rendben, megteszem."

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

A Git szolgáltatások használata

Git - „Tudnunk kell, mi változott a fejlesztés és a frissítés között. Felsorolhatja 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, milyen változások léteztek. ”

Én - „Hűvös. Háromféle változást látok. Van egy S1 szolgáltatás, amelyet másképp kell felhívnom. Van egy S2 szolgáltatás, amelyet más végpont használatával kell felhívnom. Van egy S3 szolgáltatás, amelyet különféle paraméterekkel kell felhívnom. Azt is látom, hogy a package.json fájl a frissítési ágban már tartalmaz néhány frissített csomagot. Tehát csak néhány csomagot kell cserélni. ”

Git - „Fantasztikus, hogy elkülönítette a változásokat. Most mutassa meg fejlett ágának Git naplóját. Remélem, hogy betartottál néhány alapvető Git gyakorlatot, például amikor minden egyes elkötelezettségnél mindig van építhető kód. A kötelező üzenetnek ábrázolnia kell, amit megváltoztatott. "

Jelentkezzen be a fiók fejlesztése

Én - „Igen, összesen négy kötelezettségvállalásom van a fejlesztési ágazatban. Az egyik kötelezettségvállalás a projekt felépíthetőségének javítása volt. A három szolgáltatási hívás mindegyikéhez egy van. ”

Git - „Tökéletes! Úgy tűnik, hogy megfelelően követte a bevált gyakorlatokat. Kezdjük a projektépítés stabilizálásával a package.json naprakészen tartásával. Nézze meg a frissítési ágot, és készítsen egy másolatot a package.json - package-copy.json fájlról. Most, a Git csere segítségével, frissítse a / package.json fájlt a develo / package.json fájllal, és futtassa a diffúzást a package.json és a pack-copy.json között. Mivel az élő kódban néhány csomag már megváltozott, és különböző verziói vannak, frissíteni kell a diff nézetével. ”

A projekt építhetővé tétele

Én - Hadd próbáljam meg. Rendben, épül és működik. ”

Git - „Fantasztikus! Most dolgozzunk a szolgáltatási hívásokon. Látom, hogy van egy kötelezettségvállalása minden szolgáltatáshívás-változásra a fejlesztési ágban. Ideje cseresznye felvenni. Választhat a legkevésbé bonyolult szervizhívástól a legbonyolultabb szervizhívásig. Válassza ki, egyesítse és oldja meg a konfliktusokat. Minden cseresznye szedés után és minden kötelezettségvállalás előtt ellenőrizze, hogy a projekt építhető-e. "

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

Git - „Üdvözöljük. De te te segítetted magad, követve a Git elkövetési gyakorlatait, és nem kezelve Gitet pusztán kódtárolónak. ”

Mit csináltam itt?

Változtassa meg a kapcsolódó változásokat

Vessen egy pillanatra egy szünetet, és gondolkodjon úgy, hogy ez a változás beletartozik-e ebben a kötelezettségvállalásban. Az a kötelezettségvállalás, amely azt mondja, hogy a „változás: service-s1 végpontok”, és rendelkezik a service-s2 változtatásokkal, csak zavart okozna.

Ne vállalja el a félkész munkát

Gyakran hallottuk a „korai elkötelezettség, gyakran elköteleződés” mantrát. A fenti példában egy kötelezettséget vállalhat ugyanazon szolgáltatás különböző végpontjaira. Ezt hívják kolbászkészítésnek.

Én azonban személyesen git rebase interaktív móddal próbálom kis feladataimat. Ez elősegíti egy logikai változás elvégzését, amely hitelesíthető, és elősegíti a Megbízható Biztosnak a kódod felülvizsgálatát is. Ez sokkal előnyösebb a nagyszabású projekteknél.

Tesztelje kódját, mielőtt vállalja

Git-re mint állami gépre kell gondolnunk, és minden gépnek bármilyen állapotban építhetõnek kell lennie.

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

Ez a legfontosabb rész. Mindig egy pillanatra szünetel, és azt gondolom, képes leszek-e megérteni - három hónap elteltével - a kötelezettségvállalásban bekövetkező változásokat, ha csak az elkötelező üzenetre nézem.

Következtetés

Gyorsan meg tudtam oldani a rendetlenséget. Azért jöttem ki abból a WTF és FML pillanatból, hogy csak néhány jó gyakorlatot követtem. Ok miatt léteznek, és olyanok, mint az élelmiszer sója - csak akkor veszi észre értéküket, ha nem használják őket.

A hibák előbb vagy utóbb, öntudatlanul történnek. De ügyeljen arra, hogy tudatosan kövesse néhány gyakorlatot Git környékén.

A Git szemantikai elkötelező üzeneteinek rajongója vagyok, amelyek segítenek navigálni a Git előzményeiben. Mivel, legyünk őszinték, nem számíthat arra, hogy mindenki ugyanazokat a szavakat használja minden egyes elkötelező üzenethez. Az üzenet típusa azonban várható.

Ez segít abban, hogy minden elkötelezettség után a projekt felépülhessen - ami igazán hasznos.

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

Irodalom

  • Git legjobb gyakorlatok
  • Szuper félelmetes verzióvezérlő integráció a VSCode-ba
  • Git szemantikus kötelezettségvállalási üzenetek
  • Git tipp: Hogyan lehet egyesíteni az egyes fájlokat egy másik ágból
  • Git tipp: Git - git-cherry-pick dokumentáció
  • Git tipp G: Git - git-reset dokumentáció

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