# A Git új hash alapértelmezettje – Mit jelent?

Published: 2026-10-02

A Git javasolt SHA-256 alapértelmezettje kompatibilitási határt hoz létre az új adattárak számára. Megvizsgáljuk a hivatalos tervet, Scott Chacon ellenvetését és egy működő GitHub előnézeti kivételt, majd bemutatjuk a Pi 1.0-t és a SvelteKit 3-at. Ítélet: ÁTTEKINTÉSRE SZORUL.

Canonical: https://thedailydiff.dev/hu/video/2026-10-02-git-hash-split/

## Amit ez a videó tartalmaz

- Miért tagadhatja meg két Git adattár a kommunikációt?
- Mit változtat valójában a Git 3?
- Miért cseréljük le az SHA-1-et, ha a Git észleli az ütközéseket?
- Mit mutatott a helyi kompatibilitási ellenőrzésünk?
- Mi marad meg egy összeomlás után a Pi Durable-ben?

## Fejezetek

- 0:00 Miért tagadhatja meg két Git adattár a kommunikációt?
- 0:34 Mit változtat valójában a Git 3?
- 0:58 Miért cseréljük le az SHA-1-et, ha a Git észleli az ütközéseket?
- 1:51 Mit mutatott a helyi kompatibilitási ellenőrzésünk?
- 2:49 Mi marad meg egy összeomlás után a Pi Durable-ben?
- 3:30 Mit migrál Önnek a SvelteKit 3?
- 4:03 Mit bizonyít a GitHub működő kivétele?
- 4:38 Miért függ az ítéletem az egész eszköztártól?

## Lefordított átirat

Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.

### Miért tagadhatja meg két Git adattár a kommunikációt?

0:00 Azt gondolná, a Git frissítése biztosítja, hogy az eszközei beszéljenek egymással. A Git tervezett új hash alapértelmezettje olyan adattárakat hoz létre, amelyek a mai régi formátummal nem tudnak kommunikálni. Ebben a videóban, miért változik? Mi romlik el? Ki van készen? Már létezik egy működő kivétel a GitHubon. Megmutatom, mit bizonyít a végén. Péntek van, október második, és ez a The Daily Diff.

0:18 Csütörtökön a GitHub társalapítója költséges hibának nevezte a Git tervezett változását. A Pi egy új ügynökkeretet adott ki, a SvelteKit pedig egy újabb migrációt. Scott Chacon segített a GitHub felépítésében és írta a Pro Git-et, így ez a panasz a házon belülről érkezik. A ház Git eszközöket is árul. Először is, a tényleges terv.

### Mit változtat valójában a Git 3?

0:35 A Git három az új adattárakat alapértelmezetten SHA-256-ra állítaná, amint a könyvtárak és tárhelyszolgáltatások készen állnak a támogatására. A hivatalos dokumentum nem ad kiadási dátumot és továbbra is támogatja az SHA-1-et. A meglévő adattára nem változtat varázsütésszerűen formátumot, amikor frissíti a futtatható fájlt. Ezt érdemes megjegyezni, mielőtt a csoportos csevegés sürgősségi migrációt ütemez. A dráma egy javasolt alapértelmezett, és a határidő jelenleg üres naptár.

### Miért cseréljük le az SHA-1-et, ha a Git észleli az ütközéseket?

0:58 Miért változik egyáltalán? A Git a tartalmuk hash-elésével nevezi el az objektumokat. A fájlok fákba kerülnek, és a commitok fákra és korábbi commitokra hivatkoznak. Ez biztosítja az integritást a történelem során. Változtassa meg a hash-sémát, és az objektumnevek is megváltoznak, beleértve az egyéb objektumokban tárolt hivatkozásokat is. Chacon Linus Torvaldsra, a Git alkotójára hivatkozva érvel azzal, hogy a megbízható

1:17 disztribúció számít. Ez egy történelmi álláspont, és Linus 2005-ben az SHA-1-et választotta. A biztonsági eset azóta megváltozott. A kutatók 2017-ben SHA-1 ütközéseket mutattak be, és később célzott prefix támadást mutattak be PGP identitás tanúsítványok ellen. A modern Git a megerősített SHA-1 segítségével észleli az ismert ütközési támadásokat. Fenntartói védelmet szeretnének a jövőbeli támadások ellen is, ami egy ésszerű elvárás az aláírásoktól. Chacon szerint az ökoszisztéma törvényjavaslata túl kevés biztonságot nyújt.

1:41 Azt javasolja, hogy írjanak alá egy különálló, erős ellenőrzőösszeget a fa tartalmáról, miközben megtartják a mai objektumcímzést alatta. Mi romlik el? Létrehoztam mindkét formátumot helyben, és hash-eltem ugyanazt a kis fájlt. Az egyik objektumnév negyven hexadecimális karakterből, a másik hatvannégyből áll.

### Mit mutatott a helyi kompatibilitási ellenőrzésünk?

1:54 Aztán megpróbáltam lekérni közöttük. Az telepített Git-em elutasította, algoritmus-egyezés hiánya miatt, pontosan a jelenlegi hivatalos kézikönyvben leírt kompatibilitási rés. Ez az én régi telepített Git-emet használta, így a mai határvonalról tájékoztat. A kiadatlan Git három tesztjének nevezni kreatív könyvelés lenne. A migrációs munka olyan szkriptekbe nyúlik, amelyek feltételezik egy hash hosszát, és olyan rendszerekbe, amelyek objektumnevekhez kapcsolódnak. Egy történelem újra-hash-elése térképet igényel ezen identitások között.

2:19 A Git átmeneti tervezése magában foglalja ezt a térképezést és az aláíráskezelést. A megvalósításra való készenlét számít, mert egy tervezési dokumentum nem frissíti a kedvenc fejlesztőeszköze belsejében rejtőző könyvtárat. Ez az emberi költség Chacon érvelésében. Minden eszközfenntartó kap még egy kompatibilitási feladatot, miközben a felhasználók felfedezik, hogy a verziókezelőjüknek most verziókezelésre van szüksége. Egyelőre tesztelje a gazdagépét és az eszközeit, mielőtt kiválasztja az új formátumot egy projekthez. A meglévő csapatok megtarthatják a jelenlegi formátumukat, amíg az ökoszisztéma

2:44 felzárkózik. Eközben a Pi elérte az 1.0-t. Ez egy kódoló ügynök keretrendszer az Earendil-től, natív MCP támogatással a

### Mi marad meg egy összeomlás után a Pi Durable-ben?

2:51 Codemode-on keresztül és szükség esetén betöltött eszközökkel. A csapat a minimalizmust tartja a lényegnek. Ha az ügynök beállítása már egy kis kormányra hasonlít, az eszközök távoltartása a prompttól, amíg szükséges, adminisztratív reformnak tűnik. Kiadták a Pi Durable-t is, egy különálló kísérleti keretrendszert. A feladatok mentési pontokat hoznak létre, így egy újraindított folyamat felveheti a befejezetlen munkát a tartós tárolóból. A kulcsfontosságú részlet az eszköz visszajátszása. Egy összeomlás miatt megszakított eszköz csak akkor fut újra, ha azt biztonságosnak nyilvánítja.

3:16 Ellenkező esetben a modellnek elmondják, hogy megszakították. Ez hasznos határ, amikor egy eszköz pénzt költhet. Azt akarom, hogy az asszisztens emlékezzen a bevásárlólistámra anélkül, hogy egy összeomlást kétszeri megvásárlással ünnepelne. A SvelteKit három is megérkezett csütörtökön, áthelyezve a konfigurációt a Vite-be és

### Mit migrál Önnek a SvelteKit 3?

3:30 lecserélve a dollár jelet a hash lib-re, standard csomag alútvonal importálásokkal. A migrációs parancs átírja, amit tud, és a többihez egy teendőlistát hagy. A robotod segíthet, és a differenciád továbbra is érdemes elolvasni. A bejelentés még a robot barátaidat is beszervezi a maradékokhoz. Elérjük azt a pontot, ahol egy keretrendszer-frissítés házi feladatot és egy javasolt helyettes tanárt szállít. És a távoli funkciókhoz továbbra is kísérleti Async Svelte-re van szükség. Egy fő verziószám megnyugtató érzés, de az egyes funkciók saját

3:56 érettségi címkéket hordoznak. Ellenőrizze azokat, amelyeket ténylegesen használ. Szóval ki van készen a Git új formátumára?

### Mit bizonyít a GitHub működő kivétele?

4:03 Itt van az a kivétel. Egy nyilvános GitHub adattár, amely Brian Carlson előadását tartalmazza, már egy teljes SHA-256 objektumnevet ad vissza. Közvetlenül ellenőriztem a nyilvános távoli adattárat. Az előadás diái a támogatást privát előnézetnek nevezik, és azt mondják, hogy az adattár létrehozása még folyamatban van. Tényleges haladás van a váróterem mögött. Ez bizonyítja, hogy a GitHub képes kiszolgálni ezt az előnézeti adattárat. Nulla garanciát ad arra, hogy a szokásos projektlétrehozás vagy az összes

4:24 integrációja készen áll. A kivételnek van egy engedélyhatára. Ha inkább elolvasná ezt, mint hallaná tőlem, a differenciál minden reggel megérkezik a postaládájába, ingyenesen a thedailydiff.dev címen, a link lent. Így a mai ítélet áttekintésre szorul. Megtartom az erősebb hash opciót, és az egész eszköztárat tesztelem, mielőtt megváltoztatnám az

### Miért függ az ítéletem az egész eszköztártól?

4:40 alapértelmezéseket. A kompatibilitás része a biztonsági fejlesztés szállításának. És ez a mai differenciál. Niko vagyok az Axrisi-től. Felelősségteljesen egyesítsen. SHIP IT.

## Források

- [Chacon](https://blog.gitbutler.com/git-3-sha-256) — blog.gitbutler.com
- [Git's official plan](https://git-scm.com/docs/BreakingChanges) — git-scm.com
- [Current interoperability](https://git-scm.com/docs/git-init) — git-scm.com
- [Transition design](https://git-scm.com/docs/hash-function-transition) — git-scm.com
- [Independent collision research](https://sha-mbles.github.io/) — sha-mbles.github.io
- [GitHub preview repository](https://github.com/bk2204/talk-rust-in-git) — github.com
- [Pi 1.0](https://earendil.com/posts/pi-1-0/) — earendil.com
- [Pi Durable](https://earendil.com/posts/pi-durable/) — earendil.com
- [SvelteKit 3](https://svelte.dev/blog/sveltekit-3-is-here) — svelte.dev
- [HN discussion](https://news.ycombinator.com/item?id=49924179) — news.ycombinator.com