24 kwietnia 2026 roku zmieniła się polityka GitHuba dotycząca trenowania modeli w przypadku indywidualnych planów Copilota. GitHub może teraz wykorzystywać interakcje z Copilot Free, Pro, Pro+ i Max, w tym dane wejściowe, wyjściowe, fragmenty kodu i powiązany kontekst, do trenowania i ulepszania modeli AI, o ile użytkownik nie zrezygnuje. Dane Copilot Business i Enterprise pozostają chronione umową GitHuba o ochronie danych. Co istotne, dotyczy to danych z interakcji z Copilotem, a nie prywatnych repozytoriów, które po prostu leżą nieużywane na GitHubie.
W tym samym czasie argumenty za migracją wróciły z innego powodu: publiczne, samodzielnie hostowane instancje Gita przyjmowały na siebie ciężki ruch automatyczny. Dyskusja na Hacker News zebrała przydatny zestaw relacji operatorów na ten temat: Koniec pewnej epoki dla mnie: koniec z samodzielnie hostowanym gitem.
Zostaje więc pytanie bardziej użyteczne niż „GitHub czy własny hosting?”: jaki problem właściwie próbujesz rozwiązać?
Krótka wersja
Trzy odpowiedzi. Wybierz tę, która pasuje do twojej sytuacji.
- A: Zrezygnuj i zostań. Wybierz to, gdy zmiana dotycząca trenowania Copilota jest twoim jedynym zmartwieniem, a GitHub nadal odpowiada potrzebom operacyjnym zespołu. Wyłącz ustawienie na poziomie konta i wracaj do pracy.
- B: Postaw na hybrydę. Publiczny open source zostaw na GitHubie ze względu na efekt sieciowy. Prywatny kod przenieś na samodzielnie hostowaną instancję Forgejo, Gitea lub GitLab CE za VPN-em albo listą dozwolonych adresów IP. Wybierz to, gdy publiczny zasięg i prywatna kontrola liczą się jednocześnie.
- C: Migruj w całości. Zabierz z GitHuba wszystko. Wybierz to, gdy regulacje, rezydencja danych, ład korporacyjny albo polityka wyłącznie wolnego oprogramowania wykluczają GitHuba, a zespół udźwignie koszt utrzymania.
Większość czytelników jest w pozycji A albo B. Pozycję C uzasadniają surowsze wymogi ładu, suwerenności lub wartości, a nie samo ustawienie Copilota.
Co naprawdę zmieniło się w kwietniu 2026 roku
Zmiana techniczna jest niewielka. W ustawieniach Copilota indywidualni subskrybenci mogą przestawić „Allow GitHub to use my data for AI model training” na Disabled. GitHub opisuje objęty materiał jako interakcje ze swoimi funkcjami i usługami, w tym dane wejściowe, wyjściowe, fragmenty kodu i powiązany kontekst, a nie zawartość prywatnych repozytoriów, która nigdy nie przeszła przez Copilota.
Copilot Business i Enterprise nie pokazują tego przełącznika, bo ich dane chroni umowa GitHuba o ochronie danych. W planach indywidualnych wyłączenie ustawienia odpowiada na obawę dotyczącą polityki trenowania; nie rozwiązuje jednak szerszego zastrzeżenia wobec zależności od polityki kontrolowanej przez dostawcę.
Zmiana w Copilocie może być zapalnikiem, nie będąc całą sprawą. Zespół może też przejmować się zależnością od platformy, tożsamością powiązaną z GitHubem, procesami zbudowanymi wokół Actions, rezydencją danych albo tym, jak łatwo będzie przenieść się ponownie później. To są pytania o migrację; przełącznik trenowania to tylko jedno ustawienie.
To rozróżnienie ma znaczenie: rezygnacja zmienia jedno ustawienie użycia danych, a migracja zmienia to, kto kontroluje hosting, tożsamość, integracje i politykę. Druga decyzja niesie znacznie wyższy koszt operacyjny.
Trzy stanowiska wyjaśnione
Decyzja skondensowana do trzech wierszy. Szczegóły niżej.
| Twoje zmartwienie | Odpowiedź | Co zrobić |
|---|---|---|
| Moje dane z interakcji z Copilotem używane do trenowania | Zrezygnuj i zostań (stanowisko A) | Przestaw ustawienie i wracaj do pracy |
| Prywatny kod, którego nie chcę u amerykańskiego dostawcy, + aktywny open source, którego nie chcę ukrywać | Hybryda (stanowisko B) | Prywatne repozytoria hostuj sam za VPN-em; publiczny open source zostaw na GitHubie |
| Suwerenność, branża regulowana, pryncypialne wyłącznie wolne oprogramowanie, pełna niezależność od dostawcy | Pełna migracja (stanowisko C) | Przenieś wszystko; zaplanuj koszt utrzymania w budżecie |
Stanowisko A: zrezygnuj i zostań
Jeśli jesteś samodzielnym programistą albo małym zespołem z prywatnymi repozytoriami, a twoje jedyne zastrzeżenie dotyczy domyślnego ustawienia trenowania, to jest twoja odpowiedź. Przestawienie ustawienia: minuta, raz. Własny hosting: mały rachunek za VPS, strategia kopii zapasowych, którą naprawdę testujesz, integracje do przebudowania, bo zakładały logowanie przez GitHuba, i sporadyczna aktualizacja albo odtwarzanie, które trafia w najgorszy możliwy moment.
Własny hosting wciąż może się opłacać, ale tylko wtedy, gdy ta powtarzalna praca kupuje ci coś, czego naprawdę potrzebujesz.
Najmocniejszy kontrargument: ten przełącznik też jest decyzją dostawcy. W 2026 roku GitHub przeszedł od domyślnego niewykorzystywania tych danych z interakcji do trenowania, do domyślnego ich wykorzystywania, i może zmienić politykę ponownie.
Jeśli twoją głębszą obawą jest „nigdy nie chcę, żeby amerykański dostawca podejmował jednostronne decyzje o moim kodzie”, żaden checkbox tego nie załatwi, a stanowisko A jest dla ciebie złą odpowiedzią. Przejdź od razu do stanowiska C.
Ale jeśli twoja obawa brzmi konkretnie „nie chcę, żeby moje obecne dane z interakcji z Copilotem trafiały do trenowania”, a ustawieniu GitHuba zaufasz do następnej zmiany, stanowisko A jest najtańszą poprawną odpowiedzią. Tanie i poprawne to nic wstydliwego.
Stanowisko B: postaw na model hybrydowy
Hosting hybrydowy oddziela publiczny zasięg od prywatnej kontroli.
Podział jest prosty. Publiczny open source zostaje na GitHubie: efekt sieciowy, dopływ współtwórców, Dependabot i ekosystem Actions to realna wartość. Prywatny kod przenosi się na samodzielnie hostowaną instancję za VPN-em albo listą dozwolonych IP, nigdy nieosiągalną z publicznego internetu.
To, że działa, wynika z właściwości modelu zagrożeń. Obawa o trenowanie Copilota dotyczy wyłącznie danych z interakcji wysyłanych przez GitHuba. Problem ruchu od scraperów AI (następna sekcja) dotyczy wyłącznie instancji dostępnych publicznie. Prywatna konfiguracja hybrydowa omija jedno i drugie.
Dla prywatnego zespołu liczącego od 2 do 10 osób 2 vCPU i 4 GB RAM to bezpieczniejszy punkt wyjścia dla Forgejo lub Gitea, z zapasem, jeśli indeksowanie wyszukiwania, pakiety albo CI dzielą ten sam host. Traktuj to jako wymiarowanie Forgejo/Gitea, a nie GitLab CE: poradnik GitLaba dotyczący instalacji na jednym węźle zaczyna się od 8 vCPU i 7,2 GB pamięci, jeszcze przed obciążeniem od CI.
Nie wystawiaj interfejsu webowego otwarcie na porcie 80 ani 443. Ogranicz go na poziomie zapory, proxy, VPN-a albo sieci mesh. Runnery CI mogą obsługiwać obie strony.
Wybór platformy zmienia zestaw funkcji bardziej niż sam model hybrydowy. Forgejo i Gitea pasują do lżejszej prywatnej forge; GitLab CE ma większy sens, gdy potrzebujesz też zintegrowanego stosu CI/CD i rejestru.
Kopie zapasowe da się ogarnąć, ale nie sprowadzaj ich do git bundle. Oficjalny przewodnik aktualizacji Forgejo za wiarygodną kopię uznaje zsynchronizowany snapshot całego magazynu używanego przez Forgejo z jednego punktu w czasie, a tam, gdzie to niepraktyczne, forgejo dump w parze z osobnym zrzutem PostgreSQL lub MySQL. Zarówno przy Forgejo, jak i Gitea trzymaj razem repozytoria, bazę danych, konfigurację, załączniki i dane LFS, przechowuj kopię poza serwerem i przetestuj odtwarzanie.
Lokalny klon programisty odzyska kod, ale nie zgłoszenia, użytkowników, metadane pull requestów, załączniki ani wszystkie obiekty LFS. Jeśli prywatny fork później stanie się publiczny, wtedy wypchnij go do kopii lustrzanej na GitHubie.
Stanowisko C: pełna migracja, gdy kontrola jest wymogiem
Pełna migracja pasuje najwyraźniej wtedy, gdy niezależność od dostawcy jest wymogiem, a nie preferencją.
Wyróżniają się trzy grupy: zespoły w branżach regulowanych, w których reguły audytu, rezydencji danych albo kontroli dostawcy wykluczają GitHuba; zespoły sektora publicznego lub unijne, dla których wymogi suwerenności są przepisem, a nie preferencją; oraz organizacje wyłącznie wolnooprogramowaniowe, które chcą odejść od infrastruktury należącej do Microsoftu i mają już ludzi potrafiących utrzymać usługi linuksowe.
Kosztem jest mały VPS, bieżące utrzymanie i utrata integracji. To właśnie o utracie integracji się zapomina. Wszystko, co uwierzytelnia się przez „Sign in with GitHub”, zostaje na GitHubie albo potrzebuje osobnego dostawcy tożsamości.
Planuj migrację wokół zależności, nie tylko repozytoriów. Podglądy pull requestów, zewnętrzne Actions, boty, webhooki, rejestry pakietów i integracje „Sign in with GitHub” mogą wymagać nowych poświadczeń, nowych procesów albo usług zastępczych. Gwiazdki i obserwujący nie stają się natywnymi rekordami na nowej forge, więc projekty publiczne oddają też część swojego dotychczasowego sygnału odkrywalności.
Zanim zmienisz kanoniczny remote, zrób próbę na sucho: przenieś jedno reprezentatywne repozytorium, odbuduj jego integracje, sprawdź historię zgłoszeń i pull requestów oraz udokumentuj ścieżkę wycofania. Porównanie platform przychodzi po tym audycie zależności.
Dla zespołów, które chcą zarządzania w modelu non-profit bez utrzymywania serwera, Codeberg wart jest rozważenia.
Wskazówka o suwerenności. Jeśli wybierasz własny hosting z powodu unijnej rezydencji danych, lokalizacja centrum danych ma znaczenie. Miejsca takie jak Frankfurt czy Amsterdam to nudny, ale poprawny wybór. Najtańszy VPS w Wirginii nie pomoże twojej umowie powierzenia danych.
Koszt operacyjny publicznego hostingu Gita
Publiczny własny hosting wystawia forge na ten sam ruch automatyczny, który uderza w każdą aplikację dostępną z internetu, tyle że strony repozytoriów zawierają kosztowne ścieżki, takie jak widoki blame, archiwa i historia commitów. Poniższe relacje to indywidualne doświadczenia operatorów, a nie pomiary porównawcze.
We wspomnianej wcześniej dyskusji o samodzielnie hostowanym Gicie jeden z operatorów zgłosił 37 212 377 żądań do instancji cgit w ciągu 60 dni, z czego ponad 99% sklasyfikowano jako boty.
W tej samej dyskusji kstrauser opisał zejście z około 600 000 żądań dziennie do mniej więcej 1000 na instancji Forgejo, ale dopiero po nałożeniu wyzwania opartego na JavaScripcie i ciasteczku na standardowe zabezpieczenia.
Inni operatorzy wspominali o fail2ban, blokadach GeoIP, blackholowaniu na poziomie systemów autonomicznych i przenoszeniu repozytoriów z powrotem na platformy hostowane. Te relacje pokazują możliwe scenariusze awarii; nie są uniwersalnymi wartościami odniesienia dla ruchu.
Techniczny powód, dla którego to trudne: proste ograniczanie tempa per IP potrafi zawieść wobec ruchu rotującego przez proxy w sieciach domowych. Flota scraperów potrafi rozłożyć żądania na tyle adresów IP, że żaden z osobna nie wygląda na nadużycie, a serwer i tak tonie w sumie zapytań.
Wyzwania z JavaScriptem albo ciasteczkiem potrafią ograniczyć mało wyrafinowane scrapowanie, ale mogą też zablokować użytkowników bez JavaScriptu i zaburzyć Gita po HTTPS, jeśli zastosujesz je do każdej ścieżki. Cache na CDN pomaga przy powtarzanych odczytach; przy unikalnych lub kosztownych endpointach, takich jak archiwa, widoki blame i strony pojedynczych commitów, pomaga znacznie mniej.
To, co zmienia takie wyzwanie, to ekonomia całej sprawy. Anubis staje przed forge i każe klientowi rozwiązać wyzwanie, na przykład niewielkie obliczenie proof-of-work, zanim serwer zwróci chronioną stronę, co podnosi koszt masowego przeczesywania. To złagodzenie, nie gwarancja.
Stosuj wyzwania przeglądarkowe wybiórczo. Zostaw SSH dostępne dla operacji Gita i przetestuj Gita po HTTPS, zanim obejmiesz tę ścieżkę ochroną: strona z wyzwaniem zwrócona klientowi Gita zamienia się w nieudany klon, a nie w przydatną weryfikację.
GitHub pochłania tę klasę ruchu w ramach swojej usługi hostowanej. Publiczna instancja Forgejo albo cgit zostawia planowanie pojemności, kontrolę nadużyć, cache i łagodzenie tobie. To właśnie przeniesienie obciążenia operacyjnego, a nie sam koszt oprogramowania, jest istotną częścią decyzji o migracji.
Właśnie dlatego model hybrydowy jest opcją pierwszej klasy, a nie awaryjną. Prywatny kod za VPN-em: scrapery do niego nie dotrą. Publiczny open source na GitHubie: ruchem botów zajmuje się infrastruktura antynadużyciowa GitHuba.
Jeśli mimo to chcesz publiczną forge na własnym serwerze, zaplanuj w budżecie logi, kontrolę tempa, cache, obronę przed botami, monitoring i przetestowaną ścieżkę dla ruchu Gita, która nie zależy od wyzwań przeglądarkowych. Traktuj obronę przed scraperami jako część normalnej eksploatacji, a nie przypadek brzegowy.
Kwestia efektu sieciowego dla opiekunów projektów open source
Zwracam się tu do bardzo konkretnego czytelnika: prowadzisz projekt open source. Dwudziestu współtwórców, dwieście gwiazdek i żywy system zgłoszeń. I rozważasz przeniesienie go z GitHuba.
Bądź szczery co do tego, co wymieniasz: odkrywalność dla współtwórców, domyślny znak zaufania github.com, Dependabot, CodeQL i ekosystem zewnętrzny oparty na logowaniu przez GitHuba. Nic z tego nie jest gdzie indziej niemożliwe; wszystko staje się jednak tarciem.
Reguła kciuka, którą bym zaproponował: jeśli wartość twojego projektu tkwi głównie w kodzie, własny hosting łatwiej uzasadnić.
Kod podróżuje bez problemu. Ale jeśli jego wartość mocno zależy od współtwórców, zgłoszeń, widoczności w wyszukiwarce i zaufania związanego z github.com, to odejście wymienia część tego, co sprawia, że projekt działa, na to, po czym opiekunowi robi się lżej. Uczciwa wymiana, jeśli twoje powody są wystarczająco poważne. Zła wymiana, jeśli robisz to dla zasady.
Przegląd platformy Codeberg opisuje usługę opartą na Forgejo, prowadzoną przez organizację non-profit Codeberg e.V. Dla opiekunów projektów open source oznacza to zarządzanie społecznościowe bez ciężaru utrzymywania forge na własną rękę.
Dla zespołów bliskich open source, które chcą zarządzania społecznościowego bez obowiązku aktualizowania, to mniejszy skok operacyjny niż prowadzenie publicznej forge. SourceHut to znacznie bardziej świadoma zmiana procesu pracy i wymaga osobnej oceny.
Zrób najmniejszą zmianę, która rozwiązuje problem
Zanim zmienisz zdalne repozytoria, zapisz wymaganie w jednym zdaniu: zatrzymać trenowanie na danych z interakcji z Copilotem, rozdzielić hosting publiczny i prywatny, albo usunąć GitHuba z architektury. Jeśli nie potrafisz nazwać wymagania, jeszcze nie migruj.
Przy migracji zacznij od pilotażu na jednym reprezentatywnym repozytorium. Zinwentaryzuj uwierzytelnianie, Actions, webhooki, publikowanie pakietów, środowiska podglądu, historię zgłoszeń, dane LFS i kroki wycofania, zanim zmienisz kanoniczny remote.
Cloudzy's wdrożenie Forgejo jednym kliknięciem to szybki sposób na postawienie prywatnej strony modelu hybrydowego; ręczna instalacja na dowolnym Linux VPS też się sprawdzi. Którą drogę byś nie wybrał, trzymaj interfejs webowy prywatnie, twórz kopię pełnego stanu aplikacji i przetestuj odtwarzanie, zanim przeniesiesz krytyczne repozytorium.
Twórz na VPS Linux z dostępem root, NVMe i mocą AMD EPYC.
Zobacz plany LinuxKontrola jest użyteczna tylko wtedy, gdy spełnia wymaganie przy koszcie operacyjnym, który twój zespół utrzyma na dłuższą metę.
Często zadawane pytania
Czy powinienem odejść z GitHuba z powodu zmiany w trenowaniu Copilota?
Nie automatycznie. Jeśli twoim jedynym zmartwieniem jest to, że dane z interakcji z Copilotem służą do trenowania modeli, wyłączenie ustawienia na poziomie konta jest najmniejszą poprawną naprawą. Migracja ma sens, gdy dodatkowo potrzebujesz silniejszej kontroli nad rezydencją danych, ładem, niezależnością od dostawcy lub polityką wyłącznie wolnego oprogramowania.
Czy GitHub trenuje na wszystkich moich prywatnych repozytoriach?
Nie. Omawiana tu zmiana zasad obejmuje kwalifikujące się dane z interakcji z Copilotem, w tym dane wejściowe, wyjściowe, fragmenty kodu i powiązany kontekst przesłane przez Copilota. Nie oznacza to, że każde prywatne repozytorium przechowywane na GitHubie jest automatycznie wykorzystywane do trenowania modeli.
Czy samodzielne hostowanie Gita zawsze jest bardziej prywatne?
Tylko jeśli tak go prowadzisz. Prywatna forge za VPN-em albo listą dozwolonych IP potrafi ograniczyć ekspozycję, ale instancja dostępna publicznie dokłada obowiązki łatania, monitoringu, obrony przed botami, kontroli dostępu i kopii zapasowych, które normalnie bierze na siebie GitHub.
Którą samodzielnie hostowaną platformę Gita wybrać?
Wybierz Forgejo albo Gitea, jeśli chcesz lżejszą prywatną forge. Wybierz GitLab CE, gdy zintegrowane CI/CD oraz rejestr pakietów lub kontenerów są na tyle ważne, by uzasadnić jego większe wymagania zasobowe i utrzymaniowe.
Jakiej wielkości VPS potrzebują Forgejo albo Gitea dla małego zespołu?
Dla prywatnego zespołu liczącego od dwóch do dziesięciu osób 2 vCPU i 4 GB RAM to bezpieczniejszy punkt wyjścia. Dołóż zasobów, gdy ten sam host dzielą indeksowanie wyszukiwania, pakiety, duże repozytoria albo runnery CI. GitLab CE wymiaruj osobno, bo potrzebuje więcej.
Co przetestować, zanim zmienię kanoniczny remote?
Zrób pilotaż na reprezentatywnym repozytorium. Zanim przeniesiesz wszystko, sprawdź historię zgłoszeń i pull requestów, uwierzytelnianie, Actions albo zastępcze procesy CI, webhooki, publikowanie pakietów, dane LFS, środowiska podglądu, kopie zapasowe, odtwarzanie i ścieżkę wycofania.
