Így kezeli a GitHub Copilot app a milliós kódmódosításokat

A kommentek teszik nehézzé az óriási diffek kezelését

A nagyobb átalakításokat és migrációkat gyakran egyetlen változtatásként kell beolvasztani. A GitHub szerint a halmozott pull requestek kisebb részekre bontják a munkát, így könnyebb a felülvizsgálat, és kisebb kockázattal lehet kiadni a változtatásokat. Ez azonban nem minden esetben működik tisztán, ezért egy pull requesthez idővel hatalmas diff és hosszú felülvizsgálati beszélgetés tartozhat.

Egy kódot tartalmazó diff megjelenítése önmagában jól ismert feladat. A felület csak a látható sorokat, valamint egy kisebb ráhagyást tölti be, majd görgetés közben újrahasznosítja ugyanazokat a DOM-elemeket. Így akár egymillió sor esetén is csak körülbelül 100 sor van ténylegesen megjelenítve egyszerre.

A kommenteknél azonban nem lehet előre pontosan kiszámítani a szükséges magasságot. A méret függhet a Markdown tördelésétől, a lenyitható részek állapotától, a válaszmezőtől, a képek betöltődésétől, a reakcióktól és a javasolt módosítások megjelenítésétől is.

Két külön geometria tartja gyorsan a felületet

A GitHub Copilot app korábbi diffnézete abból indult ki, hogy minden kódsor magassága előre ismert. A fejlesztők ezt a kódsorokhoz használt rendszert megtartották, a dinamikus tartalmakhoz viszont külön geometriát vezettek be.

A teljes magasságot így a pontosan ismert kódmagasság, a kommentekhez és más dinamikus elemekhez tartozó becsült vagy megmért magasság, valamint a görgetési kitöltés adja. A kódsorok elrendezése változatlan marad, amikor egy komment átméreteződik.

A dinamikus blokkok stabil azonosítót kapnak, és fájlhoz, sorhoz, valamint az érintett oldalhoz kötődnek. A rendszer nyilvántartja a magasságot befolyásoló állapotokat is, például a tartalmat, a lenyitható részek állapotát és azt, hogy aktív-e a válaszmező. A korábbi mérés akkor használható újra, ha ezek és a mérési szélesség továbbra is egyeznek.

Ez a megközelítés a GitHub szerint azért skálázható jobban, mert a dinamikus blokkok száma a kommentek számától függ, nem az összes kódsorétól.

A mérés nem szakítja meg a görgetést

A fejlesztők először minden blokkhoz külön ResizeObservert terveztek. Ezt a teljesítményhangolás során elvetették, mert a megfigyelt elem magasságának visszaírása újabb változást indíthat, a költség pedig a megjelenített blokkok számával nőhet.

A kiadott megoldás egyetlen, görgetéshez és üresjárathoz kötött mérési folyamatot használ. A mérés akkor indul, amikor a látható tartomány stabilizálódik, görgetés közben pedig teljesen szünetel. A rendszer nagyjából a nézetablak 2400 pixeles környezetében keres mérendő blokkokat, így a munka a látható tartományhoz igazodik.

A képernyőn lévő blokkok magasságát egyetlen kötegelt olvasással rögzíti, írások nélkül. A még be nem töltött, közeli blokkoknál legfeljebb egy háttérben végzett megjelenítést használ a lefoglalt hely pontosítására. A megfigyelő továbbra is jelzi az olyan változásokat, mint a válaszmezőbe gépelés, egy kép betöltése vagy egy lenyitható rész állapotváltása, de közvetlenül nem írja át a layoutot. A friss mérés az üresjárati folyamatban történik.

A GitHub 2026. szeptember 23-i beszámolója szerint ezzel a pull request nézete a kód és a felülvizsgálati beszélgetés együttes kezelésekor is a görgetés folyamatosságát célozza, még szélsőséges méretű változtatások esetén is.