2026. április 24-én megváltozott a GitHub modelltanítási szabályzata az egyéni Copilot-csomagok esetében. A GitHub mostantól felhasználhatja a Copilot Free, Pro, Pro+ és Max interakcióit, beleértve a bemeneteket, kimeneteket, kódrészleteket és a kapcsolódó kontextust, AI-modellek tanítására és fejlesztésére, hacsak a felhasználó ki nem lép ebből. A Copilot Business és Enterprise adatai továbbra is a GitHub adatvédelmi megállapodása alatt maradnak. A lényeg: ez a Copilot-interakciós adatokra vonatkozik, nem a GitHubon használatlanul heverő privát tárolókra.
Ezzel egy időben más okból is előkerültek a migrációs érvek: a nyilvános, saját üzemeltetésű Git-példányok nehéz automatizált forgalmat nyeltek el. Egy Hacker News-beszélgetés hasznos üzemeltetői beszámolókat gyűjtött össze erről a problémáról: Számomra egy korszak vége: nincs több saját üzemeltetésű git.
Így egy hasznosabb kérdés marad, mint hogy „GitHub vagy saját üzemeltetés?”: valójában melyik problémát akarod megoldani?
A rövid verzió
Három válasz. Válaszd azt, amelyik illik a helyzetedhez.
- A: Kilépés és maradás. Akkor válaszd, ha a Copilot tanítási változása az egyetlen gondod, és a GitHub továbbra is megfelel a csapat működési igényeinek. Kapcsold ki a fiókszintű beállítást, és térj vissza a munkához.
- B: Hibrid üzemeltetés. A nyilvános nyílt forráskód a hálózati hatás miatt maradjon a GitHubon. A privát kódot vidd át saját üzemeltetésű Forgejo-, Gitea- vagy GitLab CE-példányra, VPN vagy IP-engedélylista mögé. Akkor válaszd, ha a nyilvános elérés és a privát kontroll egyszerre számít.
- C: Teljes migráció. Vigyél el mindent a GitHubról. Akkor válaszd, ha szabályozás, adatrezidencia, irányítási elvárás vagy kizárólag szabad szoftvert engedő szabályzat kizárja a GitHubot, és a csapat elbírja az üzemeltetési költséget.
Az olvasók többsége az A vagy a B álláspontnál tart. A C álláspontot szigorúbb irányítási, szuverenitási vagy értékalapú követelmények indokolják, nem önmagában a Copilot-beállítás.
Mi változott valójában 2026 áprilisában
A technikai változás kicsi. A Copilot beállításaiban az egyéni előfizetők az „Allow GitHub to use my data for AI model training” kapcsolót Disabled állásba tehetik. A GitHub az érintett anyagot a funkcióival és szolgáltatásaival folytatott interakcióként írja le, ideértve a bemeneteket, kimeneteket, kódrészleteket és a kapcsolódó kontextust, nem pedig olyan privát tárolók tartalmaként, amelyek sosem mentek át a Copiloton.
A Copilot Business és Enterprise nem mutatja ezt a kapcsolót, mert adataikat a GitHub adatvédelmi megállapodása védi. Egyéni csomagoknál a beállítás kikapcsolása kezeli a tanítási szabályzattal kapcsolatos aggodalmat; nem oldja meg viszont azt a tágabb kifogást, hogy egy szállító által ellenőrzött szabályzattól függsz.
A Copilot változása lehet a kiváltó ok anélkül, hogy az egész érvelés lenne. Egy csapatot foglalkoztathat a platformfüggőség, a GitHubhoz kötött identitás, az Actions köré épített munkafolyamatok, az adatrezidencia, vagy hogy később milyen könnyen tudna újra költözni. Ezek migrációs kérdések; a tanítási kapcsoló csak egyetlen beállítás.
Ez a különbség számít: a kilépés egyetlen adatfelhasználási beállítást módosít, a migráció viszont azt, hogy ki felügyeli a hosztolást, az identitást, az integrációkat és a szabályokat. A második döntés üzemeltetési költsége sokkal nagyobb.
A három álláspont részletesen
A döntés három sorba sűrítve. A részletek lentebb.
| A te gondod | Válasz | Mit kell tenni |
|---|---|---|
| A Copilot-interakciós adataimat tanításra használják | Kilépés és maradás (A álláspont) | Állítsd át a beállítást, és vissza a munkához |
| Privát kód, amit nem akarok amerikai szolgáltatónál tartani, + élő nyílt forráskód, amit nem akarok elrejteni | Hibrid (B álláspont) | A privát tárolókat üzemeltesd magad, VPN mögött; a nyilvános nyílt forráskód maradjon a GitHubon |
| Szuverenitás, szabályozott iparág, elvi alapon kizárólag szabad szoftver, teljes szállítófüggetlenség | Teljes migráció (C álláspont) | Vigyél át mindent; tervezd be az üzemeltetési költséget |
A álláspont: kilépés és maradás
Ha egyedül dolgozó fejlesztő vagy kis csapat vagy privát tárolókkal, és az egyetlen kifogásod a tanítás alapértelmezése, akkor ez a te válaszod. Egy beállítás átkapcsolása: egy perc, egyszer. A saját üzemeltetés: egy kis VPS-számla, egy mentési stratégia, amit tényleg letesztelsz, integrációk, amiket újra kell építeni, mert GitHub-alapú bejelentkezésre épültek, és az alkalmi frissítés vagy helyreállítás, ami a lehető legrosszabbkor érkezik.
A saját üzemeltetés még mindig megérheti, de csak akkor, ha az a visszatérő munka olyasmit vesz meg neked, amire tényleg szükséged van.
A legerősebb ellenérv: az a kapcsoló szintén a szállító döntése. A GitHub 2026-ban áttért arról, hogy alapból nem használja ezeket az interakciós adatokat tanításra, arra, hogy alapból használja, és a szabályzatot megint megváltoztathatja.
Ha a mögöttes aggodalmad az, hogy „soha nem akarom, hogy egy amerikai szolgáltató egyoldalúan döntsön a kódomról”, azt semmilyen jelölőnégyzet nem oldja meg, és az A álláspont neked rossz válasz. Ugorj a C álláspontra.
Ha viszont a gondod pontosan az, hogy „nem akarom, hogy a mostani Copilot-interakciós adataim tanításba kerüljenek”, és a következő változásig megbízol a GitHub beállításában, akkor az A álláspont a legolcsóbb helyes válasz. Az olcsó és helyes megoldásban nincs semmi szégyellnivaló.
B álláspont: hibrid modell üzemeltetése
A hibrid hosztolás szétválasztja a nyilvános elérést és a privát kontrollt.
A felosztás egyszerű. A nyilvános nyílt forráskód marad a GitHubon: a hálózati hatás, a közreműködők utánpótlása, a Dependabot és az Actions ökoszisztémája valódi érték. A privát kód átköltözik egy saját üzemeltetésű példányra VPN vagy IP-engedélylista mögé, ahová a nyilvános internetről soha nem lehet eljutni.
Hogy ez működik, a fenyegetésmodell tulajdonsága. A Copilot tanításával kapcsolatos aggodalom csak a GitHubon keresztül küldött interakciós adatokra vonatkozik. Az AI-lehúzók forgalmi problémája (következő szakasz) csak a nyilvánosan elérhető példányokra vonatkozik. Egy privát hibrid felállás mindkettőt megkerüli.
Egy 2-10 fős privát csapatnál a 2 vCPU és 4 GB RAM biztonságosabb kiindulópont Forgejóhoz vagy Giteához, több ráhagyással, ha a keresési indexelés, a csomagok vagy a CI ugyanazon a gépen osztozik. Ezt Forgejo/Gitea-méretezésnek vedd, nem GitLab CE-méretezésnek: a GitLab egycsomópontos telepítési útmutatója 8 vCPU-nál és 7,2 GB memóriánál kezdődik, még a CI terhelése nélkül.
Ne tedd ki a webes felületet nyíltan a 80-as vagy 443-as porton. Korlátozd tűzfal, proxy, VPN vagy mesh hálózati szinten. A CI-futtatók mindkét oldalt kiszolgálhatják.
A platformválasztás jobban megváltoztatja a funkciókészletet, mint maga a hibrid modell. A Forgejo és a Gitea egy könnyedebb privát forge-hoz illik; a GitLab CE akkor logikusabb, ha integrált CI/CD- és registry-készletre is szükséged van.
A mentések kezelhetők, de ne redukáld őket egy git bundle-re. A Forgejo hivatalos frissítési útmutatója megbízható mentésnek a Forgejo által használt teljes tároló szinkronizált, adott időpontra vonatkozó pillanatképét tekinti, ahol pedig ez nem kivitelezhető, ott egy Forgejo dumpot külön PostgreSQL- vagy MySQL-dumppal párosítva. Akár Forgejo, akár Gitea: tartsd együtt a tárolókat, az adatbázist, a konfigurációt, a mellékleteket és az LFS-adatokat, őrizz egy másolatot a szerveren kívül, és próbáld ki a visszaállítást.
Egy fejlesztő helyi klónja a kódot vissza tudja hozni, de a hibajegyeket, a felhasználókat, a pull requestek metaadatait, a mellékleteket vagy az összes LFS-objektumot nem. Ha egy privát fork később nyilvánossá válik, akkor told fel egy GitHub-tükörre.
C álláspont: teljes migráció, amikor a kontroll követelmény
A teljes migráció akkor illik a leginkább, ha a szállítófüggetlenség követelmény, nem pedig preferencia.
Három csoport emelkedik ki: szabályozott csapatok, ahol auditra, adatrezidenciára vagy szállítói kontrollra vonatkozó szabályok kizárják a GitHubot; közszférás vagy uniós csapatok, ahol a szuverenitási elvárás előírás, nem ízlés kérdése; és kizárólag szabad szoftvert használó szervezetek, amelyek el akarnak jönni a Microsoft tulajdonában lévő infrastruktúráról, és már van Linux-szolgáltatások üzemeltetésére képes emberük.
A költség egy kis VPS, folyamatos karbantartás és az integrációk elvesztése. Épp az integrációvesztésről szoktak megfeledkezni. Bármi, ami „Sign in with GitHub” módon hitelesít, vagy a GitHubon marad, vagy külön identitásszolgáltatót igényel.
A migrációt a függőségek köré tervezd, ne csak a tárolók köré. A PR-előnézetek, a harmadik féltől származó Actions, a botok, a webhookok, a csomagregisztrációk és a „Sign in with GitHub” integrációk új hitelesítő adatokat, új munkafolyamatokat vagy helyettesítő szolgáltatásokat igényelhetnek. A csillagok és a figyelők nem lesznek natív rekordok az új forge-on, így a nyilvános projektek a meglévő felfedezhetőségi jelzésük egy részét is feladják.
Csinálj próbamenetet, mielőtt lecseréled a kanonikus remote-ot: költöztess át egy reprezentatív tárolót, építsd újra az integrációit, teszteld a hibajegy- és pull request-előzményeket, és dokumentáld a visszaállás útját. A platformok összehasonlítása e függőségi átvilágítás után jön.
Azoknak a csapatoknak, amelyek nonprofit irányítást szeretnének szerverüzemeltetés nélkül, a Codeberg megfontolásra érdemes.
Tipp a szuverenitásról. Ha uniós adatrezidencia miatt választasz saját üzemeltetést, számít az adatközpont helye. Az olyan helyszínek, mint Frankfurt vagy Amszterdam, unalmas, de helyes választás. A legolcsóbb virginiai VPS nem segít az adatfeldolgozói szerződéseden.
A nyilvános Git-hosztolás üzemeltetési költsége
A nyilvános saját üzemeltetés ugyanannak az automatizált forgalomnak teszi ki a forge-ot, amely minden internet felé nyitott alkalmazást elér, azzal a különbséggel, hogy a tárolóoldalak drága útvonalakat is tartalmaznak, például blame-nézeteket, archívumokat és commit-előzményeket. Az alábbi beszámolók egyes üzemeltetők tapasztalatai, nem mérési etalonok.
A fent említett, saját üzemeltetésű Gitről szóló beszélgetésben egy üzemeltető 37 212 377 kérésről számolt be egy cgit-példány felé 60 nap alatt, amelyek több mint 99%-át botként osztályozták.
Ugyanabban a beszélgetésben kstrauser arról számolt be, hogy egy Forgejo-példányt napi nagyjából 600 000 kérésről körülbelül 1000-re vitt le, de csak azután, hogy a szokásos védelmek fölé JavaScript- és sütialapú ellenőrzést tett.
Más üzemeltetők a fail2bant, a GeoIP-alapú blokkolást, az autonóm rendszer szintű feketelyukazást és a tárolók visszaköltöztetését említették szolgáltatott platformokra. Ezek a beszámolók lehetséges hibamintákat mutatnak; nem általános érvényű forgalmi viszonyítási pontok.
A technikai ok, amiért ez nehéz: az egyszerű IP-nkénti sebességkorlátozás elbukhat a lakossági proxykon körbeforgatott forgalommal szemben. Egy lehúzóflotta annyi IP között tudja szétteríteni a kéréseket, hogy egyik cím sem tűnik visszaélésszerűnek, miközben a szerver összesítve mégis megfullad.
A JavaScript- vagy sütialapú ellenőrzések visszafoghatják a kevésbé kifinomult lehúzást, de kizárhatják a JavaScript nélküli felhasználókat is, és megzavarhatják a HTTPS feletti Gitet, ha minden útvonalra ráteszed őket. A CDN-gyorsítótár az ismételt olvasásoknál segít; az egyedi vagy drága végpontoknál, mint az archívumok, a blame-nézetek és az egyes commitok oldalai, sokkal kevésbé.
Amit egy ilyen ellenőrzés megváltoztat, az a gazdaságosság. Anubis egy forge elé áll, és arra kényszeríti a klienst, hogy teljesítsen egy próbát, például egy kis proof-of-work számítást, mielőtt a szerver visszaadná a védett oldalt, ami drágábbá teszi a nagy tömegű begyűjtést. Ez enyhítés, nem garancia.
A böngészős ellenőrzéseket válogatva alkalmazd. Hagyd elérhetőnek az SSH-t a Git-műveletekhez, és teszteld a HTTPS feletti Gitet, mielőtt védelem alá vonnád azt az útvonalat; egy Git-kliensnek visszaadott ellenőrzőoldalból sikertelen klónozás lesz, nem hasznos ellenőrzési lépés.
A GitHub ezt a forgalomosztályt a szolgáltatása részeként nyeli el. Egy nyilvános Forgejo- vagy cgit-példány a kapacitástervezést, a visszaélés elleni védelmet, a gyorsítótárazást és az enyhítést rád hagyja. A migrációs döntésben épp ez az üzemeltetési teherátadás a lényeg, nem a szoftver nyers ára.
Épp ezért a hibrid modell elsőrangú lehetőség, nem vészmegoldás. A privát kód VPN mögött van: a lehúzók nem érik el. A nyilvános nyílt forráskód a GitHubon van: a botforgalmat a GitHub visszaélés elleni infrastruktúrája kezeli.
Ha ennek ellenére nyilvános, saját üzemeltetésű forge-ot szeretnél, tervezz be naplózást, sebességkorlátozást, gyorsítótárazást, botvédelmet, monitorozást és egy letesztelt útvonalat a Git-forgalomnak, amely nem függ böngészős ellenőrzésektől. A lehúzók elleni védekezést a normál üzemeltetés részeként kezeld, ne peremesetként.
A hálózati hatás kérdése nyílt forráskódú karbantartóknak
Itt egy nagyon konkrét olvasóhoz beszélek: te tartasz karban egy nyílt forráskódú projektet. Húsz közreműködő, kétszáz csillag és egy élő hibajegykezelő. És azon gondolkodsz, hogy elviszed a GitHubról.
Légy őszinte azzal kapcsolatban, mit adsz cserébe: a közreműködők általi felfedezhetőséget, a github.com hallgatólagos bizalmi pecsétjét, a Dependabotot, a CodeQL-t és azt a külső ökoszisztémát, amely a GitHub-bejelentkezésre épül. Ezek egyike sem lehetetlen máshol; mindegyikből viszont súrlódás lesz.
A hüvelykujjszabály, amit ajánlanék: ha a projekted értéke főként a kódban van, a saját üzemeltetés könnyebben indokolható.
A kód költözik veled. Ha viszont az értéke nagyban függ a közreműködőktől, a hibajegyektől, a keresési láthatóságtól és a github.com körüli bizalomtól, akkor az elköltözés annak egy részét cseréli el, amitől a projekt működik, arra, amitől a karbantartó jobban érzi magát. Jogos csere, ha elég nyomósak az okaid. Rossz csere, ha csak demonstrálni akarsz vele.
A Codeberg platformáttekintője egy Forgejo-alapú szolgáltatást ír le, amelyet a nonprofit Codeberg e.V. üzemeltet. A nyílt forráskódú karbantartók számára ez közösségi irányítást jelent anélkül, hogy maguknak kellene karbantartaniuk a forge-ot.
A nyílt forráskódhoz közel álló csapatoknak, amelyek közösségi irányítást szeretnének frissítési kötelezettség nélkül, ez kisebb üzemeltetési ugrás, mint egy nyilvános forge fenntartása. A SourceHut ennél jóval tudatosabb munkafolyamat-váltás, és külön mérlegelést kíván.
Csináld a legkisebb változtatást, ami megoldja a problémát
Mielőtt remote-ot cserélnél, írd le a követelményt egy mondatban: leállítani a Copilot-interakciós adatokon való tanítást, szétválasztani a nyilvános és a privát hosztolást, vagy kivenni a GitHubot az architektúrából. Ha nem tudod megnevezni a követelményt, még ne migrálj.
Migrációnál előbb egy reprezentatív tárolóval csinálj pilotot. Vedd leltárba a hitelesítést, az Actionst, a webhookokat, a csomagközzétételt, az előnézeti környezeteket, a hibajegyelőzményeket, az LFS-adatokat és a visszaállási lépéseket, mielőtt lecserélnéd a kanonikus remote-ot.
Cloudzy's egykattintásos Forgejo-telepítés gyors módja annak, hogy felállítsd egy hibrid modell privát oldalát; a kézi telepítés bármilyen Linux VPS gépen szintén működik. Bármelyik utat választod, tartsd privátban a webes felületet, mentsd le a teljes alkalmazásállapotot, és próbáld ki a visszaállítást, mielőtt kritikus tárolót költöztetnél.
Építkezz Linux VPS-en root hozzáféréssel, NVMe-vel és AMD EPYC teljesítménnyel.
Linux csomagok megtekintéseA kontroll csak akkor hasznos, ha megoldja a követelményt olyan üzemeltetési költségen, amit a csapatod hosszú távon elbír.
Gyakran ismételt kérdések
El kell hagynom a GitHubot a Copilot tanítási változása miatt?
Nem automatikusan. Ha az egyetlen gondod az, hogy a Copilot-interakciós adatokat modelltanításra használják, akkor a fiókszintű beállítás kikapcsolása a legkisebb helyes javítás. A migrációnak akkor van értelme, ha emellett szigorúbb adatrezidencia-, irányítási, szállítófüggetlenségi vagy kizárólag szabad szoftvert engedő kontrollra is szükséged van.
A GitHub az összes privát tárolómon tanít?
Nem. Az itt tárgyalt szabályzatváltozás az érintett Copilot-interakciós adatokra terjed ki, ideértve a Copiloton keresztül küldött bemeneteket, kimeneteket, kódrészleteket és a kapcsolódó kontextust. Ez nem jelenti azt, hogy a GitHubon tárolt minden privát tárolót automatikusan modelltanításra használnának.
A saját üzemeltetésű Git mindig privátabb?
Csak akkor, ha úgy is üzemelteted. Egy VPN vagy IP-engedélylista mögötti privát forge csökkentheti a kitettséget, de egy nyilvánosan elérhető példány rád tolja a foltozás, a monitorozás, a botvédelem, a hozzáférés-szabályozás és a mentés felelősségét, amit a GitHub egyébként elnyel.
Melyik saját üzemeltetésű Git-platformot válasszam?
Válaszd a Forgejót vagy a Giteát, ha könnyedebb privát forge-ot szeretnél. Válaszd a GitLab CE-t, ha az integrált CI/CD és a csomag- vagy konténerregisztráció elég fontos ahhoz, hogy indokolja a magasabb erőforrás- és karbantartási igényt.
Mekkora VPS kell a Forgejónak vagy a Giteának egy kis csapathoz?
Egy két-tíz fős privát csapatnál a 2 vCPU és 4 GB RAM biztonságosabb kiindulópont. Adj hozzá kapacitást, ha a keresési indexelés, a csomagok, a nagy tárolók vagy a CI-futtatók ugyanazon a gépen osztoznak. A GitLab CE-t külön méretezd, mert több erőforrást kér.
Mit teszteljek, mielőtt lecserélem a kanonikus remote-ot?
Csinálj pilotot egy reprezentatív tárolóval. Mielőtt mindent átvinnél, ellenőrizd a hibajegy- és pull request-előzményeket, a hitelesítést, az Actionst vagy az azt helyettesítő CI-munkafolyamatokat, a webhookokat, a csomagközzétételt, az LFS-adatokat, az előnézeti környezeteket, a mentéseket, a visszaállítást és a visszaállási útvonalat.
