a forráskódok elosztott kezelésének rendszere . A Git az egyik legnépszerűbb, megbízható és nagy teljesítményű verziókezelő rendszer, amely rugalmas eszközöket biztosít a nemlineáris fejlesztéshez, alapul véve az ágazást és az ággal való egyesítést. A történet integritásának és a visszamenőleges változtatásokkal szembeni ellenállásnak a biztosítása érdekében minden korábbi történet implicit hashelése történik minden egyes elköteleződéskor; lehetőség van a fejlesztők digitális aláírásával való hitelesítésére is az egyes címkéknél és elköteleződéseknél.
A legutóbbi kiadáshoz képest az új verzióban 745 változtatás került bevezetésre 74 fejlesztő részvételével, akik közül 18-an először vettek részt a fejlesztésben. :
- Az 1.18-as kiadástól elérhető új commit-átvitel mód, a „git rebase —rebase-merges”, felváltotta a régi „—preserve-merges” opciót, amely most már elavultnak van minősítve. A „git rebase” művelet a commitok sorozatának cseréjére szolgál egy új alap commitra, például amikor egy külön ágat, amelyen egy új funkció fejlődik, át szeretnénk helyezni a master ágra, amely tartalmazza az ágazás óta bevezetett javításokat:
o — o — o (my-feature)
/
o — o — o — o — o (master)
o — o — o (my-feature)
/
o — o — o — o — o (master)
A korábbi átfogó válaszágak szerkezetének megőrzésére szolgáló „—preserve-merges” opciót korábban úgy alkalmazhattuk, hogy interaktív módban (git rebase -i —preserve-merges) lehetőséget adott a commitok történetének szerkesztésére, azonban nem garantálta a repository teljes szerkezetének megőrzését. A mostani „—rebase-merges” mód lehetővé teszi a változások szerkezetének megőrzését a rajta levő ágon, miközben teljes interaktív műveletek sorozatát kínálja, beleértve a commitok eltávolítását, átstrukturálását és átnevezését.
Például, „—rebase-merges” a commitokat egy külön ágból egy újabb master ágra helyezve, miközben megőrizzük a rajta levő ág szerkezetét, és menet közben több változtatást is végrehajtunk a commitok megjegyzésein.
- Támogatás került hozzáadásra új ág létrehozására a két másik ág (merge base, közös ős) összeolvadási bázisának meghatározása alapján, a „git branch new A…B” és „git checkout -b new A…B” struktúrákon keresztül, ahol az „A…B” a két megadott commit közötti összeolvadási bázis meghatározását jelenti, hasonlóan ahhoz, ahogyan a „git checkout A…B” elmozdítja a HEAD-et az alap commitra, és a „diff A…B” a „B” commit és az „A” commit közös ős közötti változásokat mutatja.
Például, amikor a my-feature ág egy külön ága felett dolgozunk, a javasolt lehetőséget akkor lehet használni, ha másik ágról, például a master ágon ugyanolyan helyről akarunk indulni, ahonnan a my-feature ág ki lett vonva. Korábban ehhez kézzel kellett átnézni a változási logot, ami kellemetlenséget okozott egy nagy változási történelem esetén, majd végrehajtani a „git merge-base master my-feature” parancsot a master és my-feature ágak közötti egyesítési bázis hash kiszámításához, és új ágat létrehozni a közös ős alapján „git branch my-other-feature hash” paranccsal. A Git 2.22 verziójában két másik ág közötti egyesítési bázis alapján ág létrehozásához a „git branch my-other-feature A…B” szintaxist lehet használni;
- A „git branch —show-current” opció hozzáadása lehetővé teszi az éppen végrehajtott checkout művelettel kapott ág nevének megjelenítését;
- A „git checkout —no-overlay — dir” opció hozzáadása lehetővé teszi, hogy a checkout művelet végrehajtásakor a dir könyvtár tartalmát a master ág állapotához teljesen illeszkedő állapotba hozzuk. Például, ha a dir könyvtár lokális másolatában van egy fájl, amely hiányzik a master ágból, akkor alapértelmezés szerint a „git checkout master — dir” végrehajtásakor megmarad, de a „—no-overlay” opció megadásakor törölve lesz;
- A „git diff” parancsban egy univerzális API áll rendelkezésre az opciók elemzésére, ami lehetővé tette az opciók egységes feldolgozását a többi git segédeszközzel. Például, a „git diff” parancsban mostantól minden opció számára elérhetők az ellentétes opcióik is („—function-context” és „—no-function-context”);
- Hozzáadva egy új lehetőség, amely lehetővé teszi a „git log” kimenetében a commitokhoz csatolt kiterjesztett címkék (trailer - további információs zászlók, mint például Signed-off-by és Co-authored-by) szűrését. A címkék szűrése lehetséges kulcs és érték alapján is, például:
„git log —pretty=»%(trailers:key=Reviewed-by,valueonly)»; - Új Trace2 nyomkövető mechanizmus került hozzáadásra, amely rugalmasabb és strukturáltabb kimeneti formát kínál. A Trace2 lehetővé teszi a végrehajtott műveletekről és teljesítményadatokról szóló telemetria gyűjtését a részletesebb elemzés és hibaelhárítás érdekében (a kezelőt a felhasználó határozza meg, és semmilyen adat nem kerül külső környezetbe);
- A „git bisect” jelentés könnyen olvashatóbbá vált, amely most már világosabban kiemeli a problémás commitokat, és összesített statisztikát ad meg a változásokra vonatkozóan minden fájl szinten (a megváltozott sorok számának szintjén);
- A katalógok átnevezésének észlelésére szolgáló heurisztika átdolgozásra került annak érdekében, hogy kiküszöböljük a hamis átnevezési címkék beállítását. Kérdéses esetekben az ilyen katalógusok most konfliktusosként vannak megjelölve;
- Figyelmeztetés kimenete biztosított, amikor egy címkét egy másik címkére próbálnak beállítani, ami általában tévesen történik, és nem a megfelelő commit-ra állítja be a címkét (például a „git tag -f -m „updated message” my-tag1 my-tag2” szerkezet egy régi címkén hoz létre egy címkét, miközben a fejlesztő azt számította, hogy az új címke arra a commit-ra lesz beállítva, amire a régi címke mutat);
- A hozzáférhetőségi bitképek (diszk struktúrák, amelyek adattárolást végeznek a címekhez) generálása engedélyezve van a repók számára, amelyek tárolják az egyes commit-okhoz elérhető objektumkészletek adatait, és lehetővé teszik az alapobjektumok gyors észlelését. Ez a struktúra jelentősen csökkenti az adatok kinyerésének (git fetch) végrehajtási idejét.
Forrás: opennet.ru
