Érkezés de git 2.54 Ez egy új lépést jelent a világ legszélesebb körben használt szoftverfejlesztési verziókövető rendszerének fejlődésében. A projektközösség, amely több mint 130 emberből áll, arra összpontosított, hogy egyszerűsítse a gyakori feladatokat anélkül, hogy feláldozná a Gitre jellemző teljesítményt.
Az új funkciók közül, amelyek a leginkább érdekelhetik, egy új módszer a következőkre: átírni a történelmet Sokkal közvetlenebb módon a megosztott hookok konfigurálásának lehetősége közös konfigurációs fájlokból és belső fejlesztésekből, amelyek gyorsabb és könnyebben karbantartható adattárakat céloznak, különösen nagy vagy vállalati projektekben.
Git 2.54: Az új kiadás áttekintése
A Git 2.54 egy köztes verzió a jövőbeli 3.0 ág felé vezető úton, de olyan változásokat hoz, amelyek sok fejlesztő mindennapi munkáját befolyásolják. Egyrészt, Megjelent a kísérleti git history parancsEgyszerű előzmény-átírási műveletekhez tervezve. Továbbá a hook rendszer kibővült és modernizálódott, és mostantól a beállításokból kezelhető; a geometriai karbantartási stratégia mostantól az alapértelmezett.
Ezenkívül a már ismert parancsok is fejlesztésekbe kerültek, mint például git add -p, git replay, git status vagy git rebase parancsokvalamint a HTTP-átvitel, a GPG-aláírások megjelenítési módjának és az objektumadatbázis belső működésének módosításai. Bár ezek közül az új funkciók közül sok fejlett, hatásuk észrevehető lesz a vállalkozások, a közigazgatás és a nagy adattárakkal rendelkező nyílt forráskódú projektek általános munkafolyamataiban.
Új kísérleti parancs git history: a commitok egyszerű átírása
A Git 2.54 egyik legfontosabb újítása a következő: git-előzmények, egy még kísérleti parancs, amelyet olyan esetekre terveztek, amikor az interaktív újraalapozás használata túlzás. Eddig a helyi előzmények módosítására szolgáló elsődleges eszköz a git rebase -i, nagyon rugalmas, de összetettebb is, és hajlamosabb konfliktusos állapotokba hozni a felhasználót, amelyeket manuálisan kell megoldani.
Con git-előzmények Konkrét feladatokhoz közvetlenebb megközelítést keresnek: például javíts ki egy elgépelést egy néhány változtatással ezelőtti commit üzenetében, vagy egy túl nagyra nőtt commit kettéosztása. Az ötlet az, hogy egy kontrollált módot kínáljunk a történet módosítására anélkül, hogy egy interaktív újrabázisozás teljes gépezetét feladatlistákkal és köztes lépésekkel kellene beállítani.
reword subcommand: commit üzenetek módosítása a munkafa érintése nélkül
Az új rend által elindított első mód a következő: git history reword <commit>Amikor a Git meghívódik, a felhasználó által konfigurált szerkesztőt nyitja meg a következővel: megadott véglegesítési üzenetlehetővé téve a közvetlen módosítást. Amikor mented és bezárod a szerkesztőt, a Git átírja a commitot, és automatikusan frissíti az abból leágazó ágakat, hogy az új verzióra mutassanak.
A legfontosabb különbség az interaktív újraalapozáshoz képest az, hogy A `git history reword` függvény nem érinti sem a munkafát, sem az indexet.Csak az előzményeket frissíti. Ez különösen hasznossá teszi folyamatos integrációs környezetekben vagy automatizált szkriptekben, mivel akár csupasz adattárakon is működhet, ami gyakori a vállalatok vagy intézmények belső kódszerverein, ahol nincs hozzárendelt munkafa.
split alparancs: interaktívan feloszt egy commitot
A második mód, git history split <commit>Olyan helyzetekre tervezték, ahol egyetlen commit olyan változtatásokat tartalmaz, amelyeket külön kell választani. Futtatáskor a Git megjeleníti az adott commithoz tartozó hunokat, és lehetővé teszi, hogy kiválaszd, melyeket kell egy új szülő commitba kinyerni, hasonlóan ahhoz, ahogy a `git extract` működik. git add -p amikor eldönti, hogy mely kódrészleteket adja hozzá az indexhez.
Miután a töredékek kijelölésre kerültek, a Git létrehoz egy Új commit, amelyben a hunkokat az eredeti szülőjeként választottukMegőrzi az előző commitban nem kiválasztott módosításokat. Ezután átírja a leszármazott ágakat, hogy az új előzménystruktúrára mutassanak. A művelet ismét a munkafa aktuális tartalmának megváltoztatása nélkül fut le, csökkentve annak valószínűségét, hogy a repository egy bonyolult köztes állapotban maradjon.
Korlátozások és kompatibilitás más munkafolyamatokkal
Hogy a viselkedés kontrollálható maradjon, A git history nem támogatja az egyesítési commitokkal kapcsolatos előzményeket. és nem folytatja a műveletet, ha a művelet összevonási ütközéseket okoz. Kisebb módosításokhoz tervezték, nem pedig nagyszabású átírásokhoz, mint amilyeneket általában a git rebase -i vagy agresszívabb előzménytisztítási stratégiákat.
Belsőleg a parancsnokság a következő gépezetre támaszkodik: git visszajátszásamely kísérleti eszközként konszolidálódik a commitok reprodukálására egy másik bázison a működő fa érintése nélkül. Ennek a munkának egy része abból állt, hogy ezt a logikát egy közös könyvtárba kinyerték, így mindkettő git history mivel más jövőbeli funkciók is profitálhatnak egy modulárisabb infrastruktúrából, amely könnyebben automatizálható szkriptekből vagy harmadik féltől származó eszközökből.
Konfigurációalapú hookok: automatizálások megosztása és kombinálása
A Git 2.54 egy másik figyelemre méltó új funkciója a következő: a hookok közvetlenül a konfigurációs fájlokban definiálása, ahelyett, hogy kizárólag a könyvtárban elhelyezett szkriptekre hagyatkoznánk .git/hooks vagy a jelzett útvonalon core.hooksPathEz a változás sokkal könnyebbé teszi a csekkek megosztását a különböző adattárak között anélkül, hogy manuálisan kellene replikálni a fájlokat.
Eddig például egy kódformázó vagy egy titkos elemző alkalmazásához minden egyes commit előtt több projekten keresztül, a hook szkriptet minden egyes adattárba át kellett másolni, vagy külső hookkezelő eszközöket kellett használni. Az új megközelítéssel lehetőség van a következők meghatározására: központi horgok behelyezése ~/.gitconfig vagy a /etc/gitconfig vállalati, és hogy ezeket szükség esetén alkalmazzák.
Hookok definiálása konfiguráció és eseményenként több parancs alapján
Az új szintaxis stíluskonfigurációs kulcsokon alapul. hook.<nombre>.command y hook.<nombre>.eventAz első jelzi, hogy melyik parancs fog végrehajtódni, a második pedig a következőt adja meg: melyik hook esemény aktiválja aztpéldául egy pre-commit vagy egy pre-pushMivel ez egy szabványos konfiguráció, ezek a beállítások különböző szinteken létezhetnek: felhasználó, rendszer vagy adattár.
Továbbá a Git most már lehetővé teszi, hogy több hook van ugyanahhoz az eseményhez rendelveMás szóval, definiálhat például egy lintert és egy hitelesítőadat-szkennert, amelyek mindegyiken futnak. pre-commitanélkül, hogy manuálisan kellene egyetlen szkriptbe egyesíteni őket. A Git sorban végigmegy a konfigurációs bejegyzéseken, és végrehajtja az egyes parancsokat, miközben fenntartja a klasszikus szkript támogatását. $GIT_DIR/hooks, amely a végén is tovább fut, hogy ne sértse meg a korábbi konfigurációkat.
Horgok kezelése, hatástalanítása és belső modernizációja
Annak ellenőrzéséhez, hogy mely hookok aktívak és honnan származnak, a következő parancsot kell beépíteni: git hook listamely mindegyik eredetét mutatja, ami hasznos a kezelés során központosított konfigurációk Vállalati környezetekben, ha egy adott adattárnak ki kell zárnia egy globális fájlból örökölt hook-ot, elegendő a következő beállítást megadni: hook.<nombre>.enabled = false, anélkül, hogy törölni vagy módosítani kellene az eredeti konfigurációt.
A motorháztető alatt a Git a következőket tartalmazza: egységesítette és modernizálta számos belső funkciójának kezelésétSzámos olyan integrációs pontot, amelyeket korábban eseti útvonalakkal kezeltek, például a következőhöz tartozó hookokat: pre-push, post-rewrite vagy a receive-packMost már az új hooks API-t használják. Ez nemcsak következetességet biztosít, hanem megkönnyíti a folyamatos integrációs környezetek vagy kódkovácsoló platformok számára a jövőbeli változásokhoz való alkalmazkodást anélkül, hogy át kellene írni az egyes integrációkat.
Geometriai karbantartás, mint alapértelmezett stratégia
A korábbi verziókban a Git bevezette az úgynevezett stratégiát geometriai belül git maintenanceA nagyméretű adattárak újracsomagolási feladatainak költségeinek csökkentésére tervezett stratégia elemzi a meglévő csomagfájlokat, és olyan kombinációkat keres, amelyek az objektumok száma szerint geometriai sorozatot alkotnak, tömörítve azok tartalmát anélkül, hogy minden alkalommal teljes szemétgyűjtést kellene végrehajtani.
A Git 2.54-gyel ez a megközelítés a következővé válik: az alapértelmezett beállítás a manuális karbantartáshozAmikor fut git maintenance run A stratégia meghatározása nélkül automatikusan a geometriai megközelítést választja a rendszer, ahelyett, hogy közvetlenül a klasszikus feladathoz folyamodna. gc amely mindent egyetlen csomagba próbál csoportosítani.
A gyakorlatban ez azt jelenti A tárházak hatékonyabban karbantarthatók Ez kezdettől fogva különösen érdekes a hosszú múltra visszatekintő projektek vagy a nagy monorepozitóriumokat kezelő szervezetek számára. A geometriai stratégia inkrementális csomagokat kombinál, amikor az ésszerű, és csak egyet vesz igénybe. gc Akkor fejeződik be, amikor ténylegesen mindent egyetlen csomagfájlba fog konszolidálni. A folyamat során a commit gráf, a reflogok és más segédstruktúrák naprakészek maradnak.
Akik már beállították maintenance.strategy = geometric Nem fognak semmilyen változást észrevenni, mivel ezt a preferenciát tiszteletben tartják. És azok, akik inkább a hagyományos megközelítést részesítik előnyben, erőltetni a stratégiát gc konfigurálása maintenance.strategy = gcígy fenntartva a kompatibilitást a konzervatívabb áramlásokkal.
Interaktív és kísérleti parancsok fejlesztései
A főbb új funkciókon túl a Git 2.54 számos változtatást hoz, amelyek célja a következők: finomítsa a napi felhasználói élménytkülönösen azokban a parancsokban, amelyeket interaktívan használnak a változások kezelésére.
Finomítások a git add -py új navigációs lehetőségei között
Az interaktív mód git add -p és a kapcsolódó parancsok számos használhatósági fejlesztésen estek át. Amikor a billentyűk segítségével navigál a tömbök között J y KA Git mostantól megmutatja, hogy egy töredék korábban elfogadták vagy kihagytákelkerülve, hogy manuálisan kelljen megjegyezni minden egyes döntést.
A lehetőség is hozzáadódik --no-auto-advanceami megváltoztatja a viselkedést egy fájl egyes részeinek befejezésekor. Ahelyett, hogy automatikusan a következő fájlra ugrana, a munkamenet az aktuális fájlon marad, lehetővé téve a használatát < y > hogy nyugodtabban mozoghasson a fájlok között. Ez a munkamódszer akkor hasznos, ha a módosítások kijelölését egészében szeretné áttekinteni, mielőtt jóváhagyná őket.
git replay: nagyobb érettség a commitok újbóli végrehajtásához
A kísérleti sorrend git visszajátszásA commitok új bázison történő replikálására szolgáló, a munkafa módosítása nélküli funkció folyamatosan bővül. Ebben a verzióban mostantól a következő funkciókat is ellátja: atomikusan frissíti a hivatkozásokat Alapértelmezés szerint a parancsok kiírása helyett update-ref a normál kimeneten.
Ezenkívül tartalmaz egy módot --revert ez lehetővé teszi visszavonja a változtatásokat egy sor commitbólKépes elvetni a folyamat során üressé váló commitokat, és mostantól támogatja a történet visszajátszását a gyökér commitig. Ezek a fejlesztések jól illeszkednek a következő használatához: git history, amely ugyanarra az infrastruktúrára támaszkodik a biztonságosabb élmény érdekében.
Új opció – előzetes a git rebase-ben
Egy másik érdekes módosítás a következő hozzáadása: --trailer en git újbázisamely kihasználja a logikáját interpret-trailers mert ugyanazt a trailert add hozzá minden túllövéses commithozHosszú parancsok létrehozása helyett -x és felhívásokat tesz git commit --amend --no-edit --trailer=...A kívánt pótkocsit közvetlenül megadhatja az overrun indításakor.
Ez nagyban leegyszerűsíti az ismétlődő feladatokat, például a betűvonalak beillesztését Reviewed-by: vagy egy sor commithoz hasonló annotációk, ami gyakori a megosztott csapatokban használt formális kódellenőrzési folyamatokban.
HTTP-átvitel és aláírás-kezelés: finomított viselkedés
A hálózati kommunikáció tekintetében a Git 2.54 releváns változtatásokat vezet be a HTTP-válaszok kezelésében, valamint a commitokhoz és címkékhez kapcsolódó kriptográfiai aláírások értelmezésében.
HTTP 429 válaszkezelés és konfigurálható újrapróbálkozások
A Git HTTP-átvitele megtanulja helyesen értelmezni a kódokat 429 «Túl sok kérés»Eddig, amikor egy szerver 429-es hibát adott vissza, azt végzetes hibának tekintették, és a művelet sikertelen volt. Ettől a verziótól kezdve a Git újrapróbálkozhat a kéréssel, miközben tiszteletben tartja a fejléc értékét. Retry-After ha van ilyen, vagy egy konfigurálható késleltetés használatával az új opción keresztül http.retryAfter.
A módosításokat is hozzáadják http.maxRetries y http.maxRetryTime, amelyek lehetővé teszik szabályozza az újrapróbálkozások maximális számát és a rájuk fordított teljes időtEz praktikus vállalati környezetekben, ahol túlterhelt szerverekhez vagy szigorú kéréskorlátozó szabályzatokkal rendelkező szerverekhez kell hozzáférni, segítve a működés egyszerűsítését. fetch y push ellenállóbbnak kell lenni a szerver büntetése nélkül.
Lejárt kulcsú GPG aláírások kezelése
A biztonsággal kapcsolatban kijavítottunk egy potenciálisan félrevezető viselkedést: amikor egy commitot egy lejárt GPG-kulccsal írtak alá, a Git megjelenítette az aláírást a következő helyen: riasztó vörös színEz arra utalt, hogy az aláírás érvénytelen. Ha azonban az aláírás érvényes volt az adott időpontban, akkor annak érvényességének akkor is fenn kell maradnia, ha a kulcs azóta lejárt.
A Git 2.54 módosítja ezt a logikát, és figyelembe veszi a következőket: A kulcs lejárta előtt helyesen létrehozott aláírások érvényesek.Ez elkerüli a felesleges riasztásokat. Pontosabb képet ad a tárház történetéről, ami releváns a hosszú életciklusú projektek, például az évekig karbantartott intézményi vagy közigazgatási szoftverek esetében.
Új vizsgálati lehetőségek és előzmények testreszabása
Számos, az előzmények feltárására szolgáló parancs olyan fejlesztéseken esett át, amelyek növelik a rugalmasságukat, és lehetővé teszik az egyes esetekhez testreszabottabb kimeneteket.
A `git log -L` integrálható a standard diff gépezetekkel
A választás git log -LAz adott fájl sorainak alakulását nyomon követő függvény újra lett implementálva, hogy a kimenetét a következőn keresztül irányítsa át: szabványos Git diff mechanizmusKorábban a saját útvonalát használta, ami miatt inkompatibilis volt olyan nagyon hasznos lehetőségekkel, mint például a -S y -G (az úgynevezett "csákányok"), vagy különböző javításformátumokkal.
A Git 2.54-ben bevezetett változtatással -L kompatibilissé válik speciális tartalom- és diff formátumkeresésekideértve --word-diff o --color-movedÍgy a kimenet egy adott függvényre korlátozható, és ugyanakkor csak azokra a commitokra szűrhető, amelyek egy adott szimbólumot adnak hozzá vagy távolítanak el, ami megkönnyíti a kód auditálását és a regressziós analízist.
git blake diff algoritmus kiválasztással
A parancs hibáztasd, amely azt mutatja, hogy melyik commit vezette be a fájl minden sorát, és megtanul egy új opciót --diff-algorithmEz lehetővé teszi, hogy különböző diff algoritmusok, például hisztogram, türelem vagy minimális között válasszon a vonalhozzárendelés kiszámításakor.
A fájlon végrehajtott módosítások típusától függően Az egyik algoritmus kiválasztása a másikkal szemben világosabb eredményeket kínálhatEz csökkenti a zajt a nagy aktivitású kódelőzményekben. Azokban a környezetekben, ahol a részletes áttekintéseket nagyra értékelik, ez a szintű kontroll döntő lehet annak vizsgálatakor, hogy ki vezetett be egy adott kódblokkot.
Tárolásoptimalizálás és objektumadatbázisok
Az ebben a verzióban bekövetkezett változások nem korlátozódnak a felhasználói felületre; a Git működésén is jelentős munka történt. belsőleg rendszerezi és hozzáfér az adatokhozEz különösen jelentős hatással van a nagy adattárakra.
Inkrementális többcsomagos indexek és tömörítés
A hívások többcsomagos inkrementális indexek (MIDX)A Git 2.54 a korábbi verziókban már fejlesztett funkciókat is tartalmazza, mostantól támogatva a rétegtömörítést. Ez a mechanizmus kisebb MIDX rétegeket kombinál a hozzájuk tartozó elérhetőségi bitképekkel együtt, hogy a réteglánc mérete ésszerű maradjon.
Ez a lépés azért fontos, az inkrementális MIDX gyakorlatiassá tétele hosszú élettartamú adattárakbanpéldául nagy szervezetek vagy sokéves múltra visszatekintő közösségi projektek esetében. A rétegek tömörítése csökkenti a keresések összetettségét és javítja a teljesítményt olyan műveletekben, mint például fetch, clone részleges vagy előzményellenőrzések.
Objektumadatbázis (ODB) átstrukturálása
Belsőleg egy az objektumadatbázis API mélyreható refaktorálása (ODB). Most egy plug-and-backend kialakítást használnak, amelyben olyan funkciók, mint a read_object(), write_object() o for_each_object() Függvénymutatók segítségével kerülnek kiosztásra származás szerint.
Bár ez a változás nem azonnal látható a végfelhasználó számára, mégis megalapozza a jövőbeli alternatív tárolási háttérrendszerek vagy rugalmasabb objektumadatbázis-konfigurációk. Azon vállalatok számára, amelyeknek speciális szabályozási megfelelési követelményeik vannak, vagy integrálódniuk kell a saját tárolórendszereikkel, ez a modularitás megnyithatja az utat a testreszabottabb megoldások előtt.
Állapot, aliasok, háttérkitöltés és egyéb részletek fejlesztései
A Git 2.54 számos olyan módosítást is tartalmaz, amelyek bár kisebbek, de hozzájárulnak a mindennapi használat finomításához és a Git alkalmazkodásához a változatos nyelvi és hálózati kontextusokhoz.
a git állapota és összehasonlítása több távoli ággal
A parancs git státusz bemutatja a konfigurációs opciót status.compareBranchesAlapértelmezés szerint ez a parancs azt mutatta, hogy az aktuális ág hogyan viszonyul a beállított upstreamhez, valami tipikus dolog, mint például origin/mainAz új opcióval kérhetsz összehasonlítást a push ággal, vagy mindkettővel egyszerre.
Ez a funkció úgy van kialakítva, hogy háromszög alakú áramlások, gyakori a forkok használatakor: letölthetsz egy hivatalos távoli szerverről, és elküldheted a módosításokat egy másikra, így mindig tisztában vagy azzal, hogy hány commit választja el az egyes ágakat, ami csökkenti a meglepetéseket a tárolók szinkronizálásakor.
Álnév nemzetközi karakterekkel
Eddig a Git aliasok ASCII alfanumerikus karakterekre és kötőjelekre korlátozódtak, megakadályozva ezzel más nyelveken használt ékezetes vagy eltérő ábécés nevek használatát. Az új szintaxis gyakorlatilag bármilyen karaktert támogat, kivéve a sortöréseket és a NULL-t. Az egyeztetés nyers bájtként történik, és kis- és nagybetűérzékeny. Továbbá a shell automatikus kiegészítési rendszere frissült, hogy kezelje ezeket az aliasokat, így a Git könnyebben használható a többnyelvű csapatokban.
A Git backfill praktikusabb részleges klónokban
A kísérleti parancs git háttérkitöltésA részleges klónokban hiányzó blobok letöltésére használt parancsot is megerősítették. Korábban a parancs mindig elérhető blobokat kért le a következő helyről: HEAD az egész fában, ami különösen nagy adattárakban túlzott lehet.
A Git 2.54 támogatást ad a következőkhöz: érvek és útvonalspecifikáció áttekintéseígy a háttérkitöltés egy adott előzménytartományra korlátozható (például main~100..main) vagy bizonyos meghatározott útvonalakra (git backfill -- '*.c'), beleértve a helyettesítő karaktermintákat is. Ez sokkal könnyebbé teszi a nagyméretű részleges klónokkal való munkát, ahol csak a kód egy adott részének előzményeit kell befejezni.
Egyéb módosítások és részletes fejlesztések
A Git 2.54 változásnaplója számos apró fejlesztést tartalmaz. Ezek között van egy javítás a diff algoritmushoz. hisztogramami mostantól megakadályozza, hogy a tömörítési fázis a változáscsoportokat úgy mozgassa, hogy az megszakítsa a kiválasztott horgonyvonalakat, így tisztább és kevésbé redundáns különbségeket eredményezve.
Eszközök, mint például git config list , amely egyre inkább a konfigurációk listázásának hivatalos módjaként válik elfogadottá, git merge-file amely ezután figyelembe veszi az elérhető konfigurációt még a tárházon kívül is, valamint számos kapcsolódó segédprogramot git send-emailamelyek támogatást kapnak a klienstanúsítványokhoz és a felhasználó által kiválasztott karakterkészletek körültekintőbb kezeléséhez.
A Git fejlődése jó ütemben folytatódik a 2.54-es verzióval, amely a következőket ötvözi: látható fejlesztések a felhasználó számára, mint az új rend git history vagy konfigurálható hookok, amelyek jelentős munkát igényelnek a rendszer belső infrastruktúráján. Mindez egy robusztusabb, rugalmasabb ökoszisztéma felé mutat, amely jobban felkészült az egyre nagyobb adattárak és a sokszínűbb csapatok kihívásaira.
