GitHub'dan Taşınmalı mısınız? Geliştiriciler ve Küçük Ekipler için Bir Karar Çerçevesi

24 Nisan 2026'da GitHub'ın model eğitimi politikası bireysel Copilot planları için değişti. GitHub artık Copilot Free, Pro, Pro+ ve Max etkileşimlerini, girdiler, çıktılar, kod parçacıkları ve ilgili bağlam dahil, kullanıcı devre dışı bırakmadıkça yapay zeka modellerini eğitmek ve geliştirmek için kullanabiliyor. Copilot Business ve Enterprise verileri GitHub'ın Veri Koruma Sözleşmesi kapsamında korunmaya devam ediyor. Önemlisi şu: bu, Copilot etkileşim verileriyle ilgilidir, GitHub'da öylece duran özel depolarla değil.

Aynı dönemde taşınma tartışmaları farklı bir nedenle yeniden gündeme geldi: herkese açık, kendi sunucusunda barındırılan Git örnekleri yoğun otomatik trafiği sırtlıyordu. Bir Hacker News tartışması bu soruna dair işletmecilerden gelen yararlı bir rapor derlemesi topladı: Benim için bir dönemin sonu: artık kendi sunucumda git yok.

Geriye "GitHub mı, kendi sunucun mu?" sorusundan daha işe yarar bir soru kalıyor: aslında hangi kaygıyı çözmeye çalışıyorsun?

Kısa Versiyon

Üç yanıt. Durumunuza uyanı seçin.

• A: Devre dışı bırak ve kal. Tek derdiniz Copilot eğitim değişikliğiyse ve GitHub ekibinizin işleyişine hâlâ uyuyorsa bunu seçin. Hesap düzeyindeki ayarı kapatın ve işinize dönün.
• B: Hibrit çalıştır. Ağ etkisi için açık kaynak projeleri GitHub'da tutun. Özel kodu bir VPN ya da IP izin listesi arkasındaki kendi barındırdığınız Forgejo, Gitea veya GitLab CE örneğine taşıyın. Herkese açık erişim ile özel denetim aynı anda önemliyse bunu seçin.
• C: Tamamen taşın. Her şeyi GitHub'dan çıkarın. Mevzuat, veri ikamet yeri, yönetişim ya da yalnızca özgür yazılım politikası GitHub'ı devre dışı bırakıyorsa ve ekip işletme maliyetini kaldırabiliyorsa bunu seçin.

Okurların çoğu A ya da B konumundadır. C konumunu haklı çıkaran şey daha katı yönetişim, egemenlik veya değer gereklilikleridir, tek başına Copilot ayarı değil.

Nisan 2026'da Aslında Ne Değişti

Teknik değişiklik küçük. Copilot ayarlarında bireysel aboneler "Allow GitHub to use my data for AI model training" seçeneğini Disabled yapabiliyor. GitHub kapsanan malzemeyi, kendi özellik ve hizmetleriyle olan etkileşimler olarak tanımlıyor: girdiler, çıktılar, kod parçacıkları ve ilgili bağlam. Copilot'tan hiç geçmemiş özel depo içerikleri değil.

Copilot Business ve Enterprise'da bu anahtar görünmez, çünkü verileri GitHub'ın Veri Koruma Sözleşmesi kapsamında korunur. Bireysel planlarda ayarı kapatmak eğitim politikası kaygısını giderir; ancak sağlayıcının kontrolündeki bir politikaya bağımlı olmaya dair daha geniş itirazı çözmez.

Copilot değişikliği tetikleyici olabilir ama davanın tamamı değildir. Bir ekip aynı zamanda platform bağımlılığını, GitHub'a bağlı kimliği, Actions çevresinde kurulmuş iş akışlarını, veri ikamet yerini ya da ileride yeniden taşınmanın ne kadar kolay olacağını da önemseyebilir. Bunlar taşınma sorularıdır; eğitim anahtarı yalnızca bir ayardır.

Bu ayrım önemlidir: devre dışı bırakmak tek bir veri kullanım ayarını değiştirir, taşınmak ise barındırmayı, kimliği, entegrasyonları ve politikayı kimin denetlediğini değiştirir. İkinci karar çok daha yüksek bir işletme maliyeti getirir.

Üç Konum Açıklanıyor

Karar üç satıra sıkıştırılmış hâlde. Ayrıntılar aşağıda.

Konum A: Devre Dışı Bırak ve Kal

Özel depoları olan tek kişilik bir geliştirici ya da küçük bir ekipseniz ve tek şikâyetiniz eğitim varsayılanıysa, yanıtınız budur. Bir ayarı değiştirmek: bir dakika, bir kez. Kendi barındırmak: küçük bir VPS faturası, gerçekten test ettiğiniz bir yedekleme stratejisi, GitHub kimlik doğrulamasını varsaydıkları için yeniden kurmanız gereken entegrasyonlar ve mümkün olan en kötü anda düşen ara sıra bir yükseltme veya kurtarma işi.

Kendi sunucunuzda barındırmak yine de değerli olabilir, ama yalnızca bu tekrar eden iş size gerçekten ihtiyacınız olan bir şeyi kazandırıyorsa.

En güçlü karşı argüman: bu anahtar da bir sağlayıcı kararıdır. GitHub 2026'da bu etkileşim verilerini varsayılan olarak eğitimde kullanmamaktan varsayılan olarak kullanmaya geçti ve politikasını yeniden değiştirebilir.

Asıl kaygınız "kodum hakkında bir ABD sağlayıcısının tek taraflı karar vermesini asla istemiyorum" ise, bunu hiçbir onay kutusu çözmez ve Konum A sizin için yanlış yanıttır. Doğrudan Konum C'ye geçin.

Ama kaygınız özellikle "mevcut Copilot etkileşim verilerimin eğitimde olmasını istemiyorum" ise ve bir sonraki değişikliğe kadar GitHub'ın ayarına güveneceksiniz, Konum A en ucuz doğru yanıttır. Ucuz ve doğru olmakta utanılacak bir şey yok.

Konum B: Hibrit Bir Model Kurun

Hibrit barındırma, herkese açık erişimi özel denetimden ayırır.

Ayrım basit. Açık kaynak projeler GitHub'da kalır: ağ etkisi, katkıcı akışı, Dependabot ve Actions ekosistemi gerçek değerdir. Özel kod ise bir VPN ya da IP izin listesi arkasındaki, herkese açık internetten asla erişilemeyen kendi barındırdığınız bir örneğe taşınır.

Bunun işe yaramasının nedeni tehdit modelinin bir özelliğidir. Copilot eğitim kaygısı yalnızca GitHub üzerinden gönderdiğiniz Copilot etkileşim verileri için geçerlidir. Yapay zeka kazıyıcı trafiği sorunu (bir sonraki bölüm) yalnızca herkese açık erişilebilir örnekler için geçerlidir. Özel bir hibrit kurulum ikisini de es geçer.

2 ila 10 kişilik özel bir ekip için 2 vCPU ve 4 GB RAM, Forgejo ya da Gitea için daha güvenli bir başlangıç noktasıdır; arama dizinleme, paketler veya CI aynı sunucuyu paylaşıyorsa biraz daha pay bırakın. Bunu GitLab CE değil, Forgejo/Gitea boyutlandırması olarak alın: GitLab'ın tek düğümlü kurulum rehberi 8 vCPU ve 7,2 GB bellekten başlıyor, üstelik CI yükü hesaba katılmadan.

Web arayüzünü 80 veya 443'te herkese açık bırakmayın. Güvenlik duvarı, proxy, VPN ya da mesh ağ katmanında kısıtlayın. CI runner'ları her iki tarafa da hizmet verebilir.

Platform seçimi, özellik setini hibrit modelin kendisinden daha çok değiştirir. Forgejo ve Gitea daha hafif bir özel forge'a uyar; GitLab CE ise ayrıca entegre bir CI/CD ve registry yığınına ihtiyacınız varsa daha mantıklıdır.

OKU

Gitea vs Forgejo vs OneDev: Self-Hosted Bir Git Platformu Seçmek

Yedekler yönetilebilir, ama onları bir git bundle'a indirgemeyin. Forgejo'nun resmî yükseltme kılavuzu güvenilir yedek olarak, Forgejo'nun kullandığı tüm depolamanın eşzamanlı bir zaman noktası anlık görüntüsünü kabul ediyor; bu pratik değilse, bir Forgejo dump'ının ayrı bir PostgreSQL veya MySQL dump'ıyla eşleştirilmesini öneriyor. Forgejo için de Gitea için de depoları, veritabanını, yapılandırmayı, ekleri ve LFS verilerini bir arada tutun, bir kopyayı sunucu dışında saklayın ve bir geri yüklemeyi test edin.

Bir geliştiricinin yerel klonu kodu kurtarabilir, ama issue'ları, kullanıcıları, pull request meta verilerini, ekleri veya tüm LFS nesnelerini kurtaramaz. Özel bir çatallama ileride herkese açık hâle gelirse, onu o noktada bir GitHub aynasına gönderin.

Konum C: Denetim Bir Gereklilik Olduğunda Tam Taşınma

Tam taşınma en net şekilde, sağlayıcı bağımsızlığı bir tercih değil bir gereklilik olduğunda oturur.

Üç grup öne çıkıyor: GitHub'ı devre dışı bırakan denetim, veri ikamet yeri veya sağlayıcı denetimi kurallarına tabi düzenlemeli ekipler; egemenlik gereklilikleri tercih değil politika olan kamu ya da AB ekipleri; ve Microsoft'a ait altyapıdan çıkmak isteyen, Linux hizmetlerini işletebilecek personeli hâlihazırda bulunan yalnızca özgür yazılım kullanan kurumlar.

Maliyet küçük bir VPS, sürekli bakım ve entegrasyon kaybıdır. İnsanların unuttuğu kısım entegrasyon kaybıdır. "Sign in with GitHub" ile kimlik doğrulayan her şey ya GitHub'da kalır ya da ayrı bir kimlik sağlayıcısı gerektirir.

Taşınmayı yalnızca depolar etrafında değil, bağımlılıklar etrafında planlayın. PR önizlemeleri, üçüncü taraf Actions, botlar, webhook'lar, paket registry'leri ve "Sign in with GitHub" entegrasyonları yeni kimlik bilgileri, yeni iş akışları ya da yerine geçecek servisler isteyebilir. Yıldızlar ve izleyiciler yeni forge'da yerel kayıtlara dönüşmez; dolayısıyla açık projeler mevcut keşfedilebilirlik sinyalinin bir kısmından da vazgeçer.

Kanonik uzak depoyu değiştirmeden önce bir prova yapın: temsili bir depoyu taşıyın, entegrasyonlarını yeniden kurun, issue ve pull request geçmişini test edin ve geri dönüş yolunu belgeleyin. Platform karşılaştırması bu bağımlılık denetiminden sonra gelir.

Bir sunucu işletmeden kâr amacı gütmeyen bir yönetişim isteyen ekipler için Codeberg düşünmeye değer.

Egemenlik üzerine bir ipucu. Kendi barındırmayı AB veri ikamet yeri nedeniyle seçiyorsanız, veri merkezinin konumu önemlidir. Frankfurt ya da Amsterdam gibi konumlar sıkıcı ama doğru tercihtir. Virginia'daki en ucuz VPS, veri işleme sözleşmenize yaramaz.

Herkese Açık Git Barındırmanın İşletme Maliyeti

Herkese açık şekilde kendi sunucunuzda barındırmak, bir forge'u internete açık her uygulamayı vuran aynı otomatik trafiğe maruz bırakır; ancak depo sayfaları blame görünümleri, arşivler ve commit geçmişi gibi pahalı yollar içerir. Aşağıdaki raporlar tek tek işletmecilerin deneyimleridir, karşılaştırma ölçümleri değil.

Yukarıda anılan kendi sunucusunda Git tartışmasında bir işletmeci, 60 gün boyunca bir cgit örneğine gelen 37.212.377 isteği bildirdi; bunların %99'undan fazlası bot olarak sınıflandırıldı.

Aynı tartışmada kstrauser, bir Forgejo örneğini günde yaklaşık 600.000 istekten yaklaşık 1.000'e indirdiğini, ancak bunu standart önlemlerin üzerine bir JavaScript ve çerez sınaması ekledikten sonra başardığını aktardı.

Diğer işletmeciler fail2ban'den, GeoIP engellerinden, otonom sistem düzeyinde kara delik yönlendirmelerinden ve depoları barındırılan platformlara geri taşımaktan söz etti. Bu anlatımlar olası başarısızlık biçimlerini gösterir; evrensel trafik ölçütleri değildir.

Bunun zor olmasının teknik nedeni şu: IP başına basit hız sınırlaması, dönüşümlü konut proxy'lerinden gelen trafiğe karşı işe yaramayabilir. Bir kazıyıcı filosu istekleri yeterince çok IP'ye yayabilir; böylece tek tek hiçbir adres kötüye kullanım gibi görünmez, ama sunucu toplamda yine de boğulur.

JavaScript ya da çerez sınamaları basit kazımayı azaltabilir, ama JavaScript kullanmayan kullanıcıları da engelleyebilir ve her yola uygulanırsa HTTPS üzerinden Git'i bozabilir. CDN önbelleklemesi tekrarlanan okumalarda yardımcı olur; arşivler, blame görünümleri ve commit başına sayfalar gibi benzersiz ya da pahalı uç noktalarda çok daha az işe yarar.

Bir sınamanın değiştirdiği şey, işin ekonomisidir. Anubis bir forge'un önüne yerleşir ve sunucu korunan sayfayı döndürmeden önce istemciye bir sınamayı, örneğin küçük bir iş kanıtı hesabını tamamlatır; bu da yüksek hacimli taramayı pahalılaştırır. Bu bir hafifletmedir, garanti değil.

Tarayıcı sınamalarını seçici uygulayın. Git işlemleri için SSH'ı açık tutun ve o yolu korumaya almadan önce HTTPS üzerinden Git'i test edin; bir Git istemcisine dönen sınama sayfası, işe yarar bir doğrulama değil, başarısız bir klonlama olur.

GitHub bu trafik sınıfını barındırdığı hizmetin bir parçası olarak soğuruyor. Herkese açık bir Forgejo ya da cgit örneği ise kapasite planlamasını, kötüye kullanım denetimlerini, önbelleklemeyi ve hafifletmeyi size bırakır. Taşınma kararının önemli kısmı, yazılımın ham maliyeti değil, bu işletme devridir.

Hibrit model bu yüzden bir yedek çözüm değil, birinci sınıf bir seçenektir. Özel kod bir VPN'in arkasında: kazıyıcılar ona ulaşamaz. Açık kaynak projeler GitHub'da: bot trafiğiyle GitHub'ın kötüye kullanım altyapısı ilgilenir.

Yine de herkese açık, kendi barındırdığınız bir forge istiyorsanız; loglar, hız denetimleri, önbellekleme, bot hafifletme, izleme ve tarayıcı sınamalarına bağlı olmayan, test edilmiş bir Git trafiği yolu için bütçe ayırın. Kazıyıcı savunmasını istisnai bir durum değil, olağan işletmenin parçası sayın.

Açık Kaynak Bakımcıları İçin Ağ Etkisi Sorusu

Burada çok belirli bir okura sesleniyorum: bir açık kaynak projeyi siz sürdürüyorsunuz. Yirmi katkıcı, iki yüz yıldız ve canlı bir issue takipçisi. Ve onu GitHub'dan çıkarmayı düşünüyorsunuz.

Neyi takas ettiğiniz konusunda dürüst olun: katkıcılar tarafından keşfedilebilirlik, github.com'un örtük güven damgası, Dependabot, CodeQL ve GitHub kimlik doğrulamasına dayanan üçüncü taraf ekosistemi. Bunların hiçbiri başka yerde imkânsız değil; ama hepsi sürtünmeye dönüşür.

Önereceğim pratik kural şu: projenizin değeri esas olarak koddaysa, kendi sunucunuzda barındırmayı savunmak daha kolaydır.

Kod yolculuk eder. Ama değeri büyük ölçüde katkıcılara, issue'lara, aramada görünürlüğe ve github.com etrafındaki güvene bağlıysa, ayrılmak projeyi işler kılan şeyin bir kısmını, bakımcıyı daha iyi hissettiren şeyle takas eder. Nedenleriniz yeterince büyükse meşru bir takas. Bir mesaj vermek için yapıyorsanız kötü bir takas.

Codeberg'in platform tanıtımı kâr amacı gütmeyen Codeberg e.V. tarafından işletilen, Forgejo tabanlı bir hizmeti anlatıyor. Açık kaynak bakımcıları için bu, forge'u kendiniz işletmenin bakım yükü olmadan topluluk yönetişimi demektir.

Yükseltme yükümlülüğü olmadan topluluk yönetişimi isteyen, açık kaynağa yakın ekipler için bu, herkese açık bir forge işletmekten daha küçük bir işletme sıçramasıdır. SourceHut ise çok daha bilinçli bir iş akışı değişikliğidir ve ayrı bir değerlendirme gerektirir.

Sorunu Çözen En Küçük Değişikliği Yapın

Uzak depoları değiştirmeden önce gereksinimi tek cümleyle yazın: Copilot etkileşim verileriyle eğitimi durdurmak, herkese açık ve özel barındırmayı ayırmak, ya da GitHub'ı mimariden çıkarmak. Gereksinimi adlandıramıyorsanız, henüz taşınmayın.

Bir taşınmada önce temsili tek bir depoyla pilot yapın. Kanonik uzak depoyu değiştirmeden önce kimlik doğrulamayı, Actions'ı, webhook'ları, paket yayınlamayı, önizleme ortamlarını, issue geçmişini, LFS verilerini ve geri dönüş adımlarını envanterleyin.

Cloudzy'nin tek tıkla Forgejo kurulumu hibrit bir modelin özel tarafını kurmanın hızlı bir yoludur; herhangi bir Linux VPS üzerine elle kurulum da işini görür. Hangi yolu seçerseniz seçin, web arayüzünü özel tutun, uygulamanın tüm durumunu yedekleyin ve kritik bir depoyu taşımadan önce geri yüklemeyi test edin.

Denetim ancak, ekibinizin sürdürebileceği bir işletme maliyetiyle gereksinimi karşıladığında işe yarar.

Sıkça Sorulan Sorular

Copilot eğitim değişikliği yüzünden GitHub'dan taşınmalı mıyım?

Otomatik olarak hayır. Tek kaygınız Copilot etkileşim verilerinin model eğitiminde kullanılmasıysa, hesap düzeyindeki ayarı kapatmak en küçük doğru çözümdür. Taşınmak, ayrıca daha güçlü veri ikamet yeri, yönetişim, sağlayıcı bağımsızlığı ya da yalnızca özgür yazılım denetimlerine ihtiyacınız olduğunda anlam kazanır.

GitHub tüm özel depolarım üzerinde eğitim yapıyor mu?

Hayır. Burada tartışılan politika değişikliği, Copilot üzerinden gönderilen ve kapsama giren etkileşim verilerini içerir: girdiler, çıktılar, kod parçacıkları ve ilgili bağlam. Bu, GitHub'da saklanan her özel deponun otomatik olarak model eğitiminde kullanıldığı anlamına gelmez.

Git'i kendi sunucunuzda barındırmak her zaman daha mı gizlidir?

Yalnızca öyle işletirseniz. Bir VPN ya da IP izin listesi arkasındaki özel bir forge maruziyeti azaltabilir; ama herkese açık erişilebilir bir örnek, GitHub'ın normalde üstlendiği yama, izleme, bot hafifletme, erişim denetimi ve yedekleme sorumluluklarını size ekler.

Hangi kendi sunucumda barındırılan Git platformunu seçmeliyim?

Daha hafif bir özel forge istiyorsanız Forgejo ya da Gitea'yı seçin. Tümleşik CI/CD ile paket veya konteyner registry'si, daha yüksek kaynak ve bakım gereksinimini haklı çıkaracak kadar önemliyse GitLab CE'yi seçin.

Küçük bir ekip için Forgejo ya da Gitea ne büyüklükte bir VPS ister?

İki ila on kişilik özel bir ekip için 2 vCPU ve 4 GB RAM daha güvenli bir başlangıç noktasıdır. Arama dizinleme, paketler, büyük depolar veya CI runner'ları aynı sunucuyu paylaştığında kapasite ekleyin. GitLab CE'yi ayrıca boyutlandırın, çünkü daha fazla kaynak ister.

Kanonik uzak depoyu değiştirmeden önce neyi test etmeliyim?

Temsili bir depoyla pilot yapın. Her şeyi taşımadan önce issue ve pull request geçmişini, kimlik doğrulamayı, Actions ya da yerine geçen CI iş akışlarını, webhook'ları, paket yayınlamayı, LFS verilerini, önizleme ortamlarını, yedekleri, geri yüklemeyi ve geri dönüş yolunu doğrulayın.