Az elosztott forrás vezérlőrendszer Git 2.22 kiadása

Által benyújtott az elosztott forrásvezérlő rendszer kiadása git 2.22.0. A Git az egyik legnépszerűbb, legmegbízhatóbb és nagy teljesítményű verziókezelő rendszer, amely rugalmas, nem lineáris fejlesztőeszközöket biztosít elágazáson és ágak összevonásán alapulóan. Az előzmények integritásának és az utólagos változásokkal szembeni ellenállásnak biztosítása érdekében minden egyes commit során a teljes korábbi előzmény implicit kivonatolása történik, valamint lehetőség van az egyes címkék és commitok fejlesztőinek digitális aláírásának ellenőrzésére is.

A 745 fejlesztő közreműködésével készült új verzióba az előző kiadáshoz képest 74 változtatást fogadtak el, ebből 18 először vett részt a fejlesztésben. A főbb innovációk:

  • Az 1.18-as kiadás óta elérhető új, „git rebase --rebase-merges” commit set migrációs mód felváltotta a régi „--preserve-merges” opciót, amely mára elavult. A "git rebase" műveletet arra használják, hogy egy sor véglegesítést lecseréljenek egy új alap véglegesítésre, például egyetlen ág áthelyezésére, amely valamilyen új szolgáltatást fejleszt a fő ág jelenlegi állapotába, amely magában foglalja az elágazás után hozzáadott javításokat is:

    o - o - o (saját funkció)

    /

    o - o - o - o - o (mester)

    o - o - o (saját funkció)

    /

    o - o - o - o - o (mester)

    Az áttelepített ágban az ág szerkezetének megőrzésére korábban a „--preserve-merges” opciót lehetett használni, amely interaktív módban futtatva (git rebase -i --preserve-merges ) lehetővé tette a véglegesítési előzmények szerkesztését, de nem garantálta a tároló szerkezetének teljes megőrzését. A helyettesítő "--rebase-merges" mód lehetővé teszi az áttelepített ág változásainak struktúrájának megtartását, miközben az interaktív műveletek teljes készletét biztosítja, beleértve a véglegesítések törlését, átcsoportosítását és átnevezését.

    Például: "--rebase-merges" lehetővé teszi a véglegesítéseket egy külön ágról egy újabb fő ágra tolja át, miközben az ág szerkezetét az áttelepített ágban tartja, és menet közben hajtson végre néhány változtatást a véglegesítési megjegyzéseken.

  • Támogatás hozzáadva egy új ág létrehozásához két másik ág egyesítési bázisának meghatározása alapján (egyesítési alap, kötés közös őshöz) a „git branch new A…B” és a „git checkout -b new A…B” használatával. ” konstrukciók, amelyekben az „A ...B” azt jelenti, hogy meg kell határozni az összevonási bázist a két megadott véglegesítés között, hasonlóan ahhoz, ahogy a „git checkout A...B” eltolja a HEAD-et az alap véglegesítéshez és a „diff A...B”-hez. megmutatja a változásokat a "B" véglegesítés és az "A" véglegesítéssel megosztott között. » őse.

    Például, amikor egy külön saját szolgáltatási ágon dolgozik, a javasolt szolgáltatás akkor használható, ha egy másik ágról szeretne indulni, például a fő ág ugyanarról a helyéről, ahonnan a saját szolgáltatás ágat kivette. Korábban ehhez manuálisan kellett megvizsgálni a változásnaplót, ami kényelmetlen volt, ha nagy változástörténet volt, majd a "git merge-base master my-feature" műveletet kellett elvégezni, hogy kiszámítsa az egyesítési bázis hash-értékét a fő és a saját szolgáltatás ágak között, és új ág létrehozása a közös ős" git ág más funkció hash"-hez képest. A Git 2.22-ben a "git ág, a másik szolgáltatásom A…B" szintaxist használhatja két másik ág egyesítési alapjához viszonyított ág létrehozásához;

  • A "git branch --show-current" opció hozzáadva a fizetési műveletből kapott ág nevének megjelenítéséhez;
  • Hozzáadtuk a "git checkout --no-overlay -- dir" opciót, amely lehetővé teszi, hogy a fizetési művelet végrehajtásakor a dir könyvtár tartalmát olyan formába hozza, amely teljes mértékben megfelel a fő ág állapotának. Például, ha a dir könyvtár helyi másolatában van egy fájl, amely nem a fő ágban található, akkor alapértelmezés szerint a "git checkout master - dir" végrehajtásakor ez megmarad, és amikor a "--no-overlay " opció megadva, törlésre kerül;
  • A „git diff” parancs egy általános beállításelemző API-t használ, hogy egyesítse az opciófeldolgozást más git-segédprogramokkal. Például a "git diff"-ben most már minden opciónak elérhető az antagonistája ("--function-context" és "--no-function-context");
  • Hozzáadtuk a szűrési lehetőséget a véglegesítésekhez csatolt „git log” kiterjesztett címkék kiadásakor („trailer” – további információs jelzők, mint például a Signed-off-by és Co-authored-by). Lehetőség van a címkék kulcs és érték szerinti szűrésére is, például:
    "git log --pretty="%(trailers:key=Reviewed-by,valueonly)";

  • Egy új nyomkövető motor, a Trace2 került hozzáadásra, amely rugalmasabb és strukturáltabb kimeneti formátumot kínál. A Trace2 lehetővé teszi a telemetriai adatok gyűjtését az elvégzett műveletekről és teljesítményadatokról a részletesebb elemzés és hibakeresés érdekében (a kezelőt a felhasználó rendeli hozzá, kívülre nem küldenek adatokat);
  • Olvashatóbbá tette a "git bisect" jelentést, amely most már világosabban kiemeli a problémás véglegesítéseket, és megjeleníti az egyes fájlok változásainak összesített statisztikai adatait (a módosított sorok számának szintjén);
  • A címtár-átnevezések észlelésének heurisztikáját újratervezték, hogy elkerüljék az átnevezési jelzők téves beállítását. Ha kétségei vannak, az ilyen könyvtárakat most ütközőként jelöli meg;
  • Figyelmeztetés jelenik meg, amikor egy címkét egy másik címkére próbálnak beállítani, ami általában tévedésből történik, és a címke rossz véglegesítésre való beállításához vezethet (például egy olyan konstrukció, mint a "git tag -f -m " frissített üzenet" my-tag1 my- tag2" egy címke létrehozását eredményezi a régi címkén, miközben a fejlesztő arra számított, hogy az új címke be lesz állítva a régi címke által mutatott véglegesítésnél);
  • A generálás engedélyezve van a bittérképes tárolókhoz (lemezstruktúra "elérhetőségi bittérképek"), amelyek adatokat tárolnak az egyes véglegesítésekhez elérhető objektumkészletekről, és lehetővé teszik az alapul szolgáló objektum jelenlétének gyors meghatározását. A megadott struktúra jelentősen csökkenti az adatkinyerési műveletek (git fetch) végrehajtási idejét.

Forrás: opennet.ru

Hozzászólás