GitHub'dan Codeberg'e geçiş: üşengeçler için bir yöntem

 (unterwaditzer.net)
1 puan yazan GN⁺ 2026-03-27 | 1 yorum | WhatsApp'ta paylaş
  • Bazı projeleri GitHub'dan Codeberg'e taşırken, en az çabayla geçişe başlamanın yolunu derliyor
  • Codeberg'in depo içe aktarma özelliği sayesinde issue, PR ve release'leri de kapsayan tam bir geçiş mümkün; arayüz ve iş akışı GitHub'a benziyor
  • Statik sayfa barındırma için codeberg.page kullanılabilir; grebedoc.dev ve statichost.eu gibi alternatifler de mevcut
  • En büyük zorluk CI ortamını kurmak; GitHub'ın macOS runner'larından ve ücretsiz çalışma kotasından vazgeçmek gerekiyor, bunun yerine Forgejo Actions veya Woodpecker CI kullanılabiliyor
  • Geçişten sonra GitHub deposunu salt okunur bir arşiv olarak tutmak veya aynalamak, açık kaynak ekosistemiyle bağı tamamen koparmamanın bir yolu olarak öneriliyor

GitHub'dan Codeberg'e geçiş süreci

  • Bazı depoları GitHub'dan Codeberg'e taşımaya başlama deneyimine dayanarak, gerçek geçiş sürecinin zorluk ve kolaylık düzeyi anlatılıyor
    • Codeberg'in yeterince hazır olmadığını düşünüp bunu ertelemiş olsa da, projeye bağlı olarak geçiş beklenmedik ölçüde kolay olabilir
    • Hedef kusursuz bir kurulum değil, geçişe başlamanın en kolay yolunu bulmak

  • Depo ve issue taşıma

    • Codeberg, GitHub depo içe aktarma (import) özelliği sunuyor; issue, PR, release ve bunların artifact'leri birlikte taşınabiliyor
      • Bu süreçte issue numaraları, etiketler ve yazar bilgileri aynen korunuyor
      • Codeberg'in arayüzü GitHub ile neredeyse aynı ve başka bir issue tracker'dan GitHub'a geçerken gereken karmaşık adımlara kıyasla çok daha basit bir deneyim sunuyor

  • Statik sayfa barındırma

    • GitHub Pages kullanılıyorsa, bunun yerine codeberg.page kullanılabiliyor
      • Resmî bir erişilebilirlik garantisi (SLO) yok, ancak pratikte hiç kesinti yaşamadığını belirtiyor
      • HTML'i bir branch'e push etme yöntemiyle çalışıyor; GitHub Pages'a benzer bir yapı sunuyor
      • Alternatif olarak grebedoc.dev veya statichost.eu da kullanılabilir

  • CI (sürekli entegrasyon) ortamının zorlukları

    • Geçiş sırasında en zorlu kısım CI ortamını kurmak
      • GitHub, ücretsiz macOS runner'ları ve genel depolar için sınırsız çalışma kotası sunuyor; Codeberg'de ise bunlardan vazgeçmek gerekiyor
      • Çözüm olarak dile özel çapraz derleme ve Forgejo Actions runner'ını self-host etme yöntemleri kullanılabilir

    • Forgejo Actions ve Woodpecker CI

      • Codeberg'de Woodpecker CI daha kararlı, ancak Forgejo Actions, GitHub Actions kullanıcıları için daha tanıdık bir ortam sunuyor
      • Arayüz ve YAML sözdizimi neredeyse aynı; mevcut GitHub Actions workflow'larının çoğu doğrudan çalışıyor
      • Örneğin GitHub Actions'ta uses: dtolnay/rust-toolchain kullanılan yeri, Forgejo Actions'ta uses: https://github.com/dtolnay/rust-toolchain olarak değiştirmek yeterli
      • Şu anda Codeberg'in Forgejo Actions belgeleri güncel değil ve bununla ilgili bir PR mevcut

    • macOS runner gerektiğinde

      • macOS derlemesi gerçekten gerekiyorsa, GitHub Actions'ı kullanmaya devam edip Codeberg deposundan GitHub'a commit'leri aynalamak mümkün
      • Forgejo Actions, GitHub API'sini poll ederek CI durumunu Codeberg ile senkronize edecek şekilde ayarlanabiliyor
      • macOS build sunan başka CI servisleri de denenmiş, ancak Codeberg ile entegrasyonları GitHub Actions kadar basit değil

  • GitHub deposunu nasıl ele almak gerekir

    • Geçişten sonra GitHub deposu için README güncellenip arşivleniyor
      • Codeberg'den GitHub'a commit push edecek şekilde de ayarlanabilir, ancak bu durumda kullanıcılar hâlâ PR açabilir ve issue yorumları yazabilir
      • Bazıları GitHub deposunda issue özelliğini devre dışı bırakıyor, ancak bu durumda tüm issue'lar 404 olarak kayboluyor ve PR'leri devre dışı bırakmak mümkün değil
      • Örnek olarak libvirt/libvirt deposu, tüm PR'leri otomatik kapatan bir GitHub Action kullanıyor
    • Bu yaklaşım, self-hosting ve genel açık kaynak ekosistemi üzerinde olumsuz etki yaratabilir
      • Kullanıcılar build optimizasyonlarını veya release dosyalarının indirilme sıklığını iyileştirme motivasyonunu kaybedebilir
      • Geçiş döneminde salt okunur bir mirror tutmak veya GitHub Pages ve Actions'ı birlikte kullanmak da düşünülebilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-27
Hacker News yorumları

  • Codeberg’in kendisinden nefret etmiyorum ama GitHub’ın tam bir alternatifi değil
    Kişisel kod depoları ya da deneysel script’ler yüklemek için kısıtlar fazla ve özel depolar 100MB ile sınırlı
    GitHub Pages gibi bir ana sayfa da barındıramıyorsunuz. Bu tür kullanım için Forgejo’yu self-host etmek daha gerçekçi bir alternatif
    İlgili bilgiler Codeberg FAQ içinde iyi özetlenmiş

    • Codeberg’de de Codeberg Pages özelliğiyle ana sayfa barındırılabiliyor
    • Ben de web sitemi Codeberg Pages üzerinde yayınlayıp çalıştırıyorum. Yukarıdaki bilgi yanlış → Codeberg Pages dokümantasyonu
    • “Kendi git sunucunu çalıştırmak zahmetli” sözüne katılmak zor. Sadece kodu push’layacak bir alan istiyorsanız tek bir SSH sunucusu yeter
    • Pierre’in yaptığı Code Storage projesi, bu işletme yükünü azaltan API tipi git sunucusu olarak ilginç
    • (Biraz tanıtım da yapayım) Monohub adında bir GitHub alternatifi geliştiriyorum. Özel depoları varsayılan olarak sunuyor, PR da destekliyor. Genel depo örneği

  • OSS projelerimi GitHub’a koymamın nedeni basit — topluluk orada olduğu için
    Sadece kod koyacaksam doğrudan SSH ya da SFTP ile kendim host ederim

    • Topluluğun sadece GitHub’da kalması bir tavuk mu yumurtadan, yumurta mı tavuktan meselesi. Sonuçta birilerinin önce başka bir platforma taşınması gerekiyor ki ekosistem de hareket etsin
      Ben sadece kişisel Gitea instance’ıma yüklüyorum ve yıldız ya da tanıtımı umursamıyorum
    • GitHub’da kalan şey sadece kapalı bağımlılığı kabullenen FOSS topluluğu. Hatta GitHub’ın politikaları insanları uzaklaştırıyor
    • Bazı projelerde GitHub hesabınız yoksa katkı sunmanız bile mümkün değil. Örneğin crates.io issue 10 yıldır çözülmedi ve Lean’in Reservoir sistemi GitHub’da en az 2 yıldız istiyor. Bu, Microsoft bağımlılığını güçlendirme gibi görünüyor
    • GitHub ücretsiz olarak çok fazla CI kaynağı sağlıyor. Özellikle macOS runner’ların neredeyse alternatifi yok. Bu sayede farklı ortamlarda test yapılabiliyor
    • Ben de GitHub’dan uzaklaşmak için ev sunucumda Git hosting başlattım ama eskiden commit push’larken aldığım dopamin kayboldu. Açık kaynağın ticarileşmesiyle cazibesi azalmış gibi geliyor

  • Ben tüm kişisel projelerimi Forgejo self-hosting ile yönetiyorum. GitHub’ı hiç aramıyorum
    Tailscale ile erişimi kısıtlayıp AI crawler’ları da engelleyebiliyorsunuz

    • Ben de yıllardır Forgejo’yu kendim çalıştırıyorum. Hatta bir kurulum rehberi de yazdım ve yakın zamanda Hetzner üzerinde 2 Raspberry Pi’ye taşıdım. GitHub’dan daha hızlı ve daha kararlı
    • Eskiden GitLab kullanıyordum ama Forgejo çok daha hafif bir Go tek-binary çözümü olduğu için daha az kaynak tüketiyor. Docker ile kolayca çalışıyor ve özellikleri kendin hack’lemenin keyfi de büyük
    • GitHub’da agent hesabı oluşturma engellendiğinde Forgejo kurdum; 15 dakika içinde PR incelemesinde “Viewed dosyaları gizle” özelliğini kendim ekledim
    • Son dönemde büyük OSS projeleri Forgejo’ya taşınırken ben de peşlerinden gittim ve şu ana kadar çok memnunum
    • Ben de Docker ile Forgejo runner kurup CI çalıştırıyorum. Kendi registry’si olduğu için uygulamaları Docker image olarak dağıtıyorum

  • Bundan sonra GitHub alternatiflerini değerlendirmek giderek daha önemli olacak gibi görünüyor
    Ama GitHub, CI ve multi-architecture build standardını fiilen oluşturduğu için topluluk odaklı alternatiflerin rekabet etmesi zor

    • CI’ın illa GitHub’a bağımlı olması gerekmiyor. Aslında çoğu CI sadece basit bir komut çalıştırıcısı. Küçük ekipler için CI olmadan da gayet yürünebilir
    • CI’ı kendin çalıştırmanın neden mantıksız olduğunu anlamıyorum. Repo ile CI’ı ayırmak sorun değil
    • Benim için CI’dan çok PR ve code review deneyimi önemli. GitHub’ın hâlâ rahatsız edici yanları var ve issue sistemi de 20 yıl öncesinde kalmış gibi
    • Bu tür merkezileşmiş katmanlar sonuçta kontrol etme isteğinden kaynaklanıyor. Yerel odaklı dağıtık workflow’larla da gayet keyifli geliştirme yapılabiliyor

  • GitHub birçok şeyi “ücretsiz” veriyor ama bunun karşılığında veri toplama ve eğitim için kullanma ihtimali yüksek
    Codeberg özel depoları desteklemediği için Copilot’ın genel depoları taramasını da engelleyemiyor
    Codeberg FAQ’a göre özel proje gerekiyorsa Forgejo self-hosting öneriliyor

    • Ama benim Codeberg depom özel olarak ayarlı. Yani tamamen imkânsız değil gibi görünüyor

  • Şirketimiz GitHub’dan tamamen GitLab self-hosting’e geçti
    Tailscale arkasına koyduğumuz için SSO yükü yok ve CI runner’lar EKS ile GPU cluster üzerinde çalışıyor. Benzer bir geçişi düşünenlere yardımcı olabilirim

    • Forgejo’yu da değerlendirip değerlendirmediğinizi merak ediyorum. GitLab enterprise düzeyinde CI/CD konusunda güçlü ama küçük projeler için Forgejo daha hafif bir seçenek olabilir
    • Self-hosted GitLab’da otomatik kullanıcı provisioning’i (SCIM) gibi özellikler destekleniyor mu, onu da merak ediyorum

  • Sadece “GitHub’ı değiştirelim” demek anlamlı değil. Yeni alışkanlıklar ve yeni bir değer önerisi gerekiyor
    GitHub, SourceForge’un yerini aldığı gibi, yeni nesil platformun da kod yazmayı ve iş birliğini gerçek zamanlı bağlaması gerekir
    Örneğin Google Docs gibi her prompt için bir commit üretilen bir yapı olabilir

    • Ama işin içinde ciddi jeopolitik nedenler de var. ABD teknoloji bağımlılığından kaçınma hareketi Avrupa gibi yerlerde canlı
    • Son dönemdeki Copilot tartışmaları güveni sarstığı için GitHub’dan ayrılma eğilimi oluşuyor
    • Benim için önemli olan şey sadece özellikler değil, erişilebilirlik (uptime). GitHub bugünlerde %99’u bile tutturamıyor

  • Codeberg idealist ama pratikte kararlılık sorunları büyük
    Cloudflare olmadan çalıştığı için DDoS saldırılarına açık ve sık sık kesinti yaşıyor. Geliştirme sırasında uzak depoya erişememek gerçekten sinir bozucu

    • Ben GitHub ya da Codeberg’i sadece asenkron kod paylaşımı için kullanıyorum. Uzak taraf ölse bile yerelde çalışmaya devam edebilmelisiniz
    • Cloudflare’dan hoşlanmıyorum ama pratikte bot trafiği ve saldırı savunması için gerekli. Alternatif hizmetler ise daha sık engellendi ya da daha dengesizdi. İlke ile gerçeklik arasındaki farkı çok net hissediyorum
    • GitHub’ın çalışma durumu izleme verisine bakınca son 90 günde %90 seviyesinde olduğu görülüyor. Hatta Codeberg daha kararlı
    • Kişisel git sunucumun performansı da AI crawler’ların ayrım gözetmeyen scraping’i yüzünden düştü. Sonunda büyük şirketlerin IP’lerini topluca engelledim
    • git’in özü dağıtık yapısıdır. Uzak taraf ölse bile en güncel sürümün yerelde olması gerekir

  • Microsoft satın almasından sonra GitHub’ı neredeyse hiç kullanmıyorum. Sourcehut’ın sade e-posta tabanlı workflow’u bana daha çok hitap ediyor
    CI için de sadece yerelde çalıştırılabilen komut tabanlı bir yapı yeterli diye düşünüyorum

  • Kod depoları doğası gereği dağıtık ve federatif bir yapıda olmalı
    git’in kriptografik imza sistemi (GPG/SSH) sayesinde depo güveni ile commit güvenini ayırabilirsiniz
    Merkezde yalnızca anahtar sunucusu ve namespace yönetimi bırakılıp geri kalanı dağıtılabilir

    • Radicle tam olarak böyle bir dağıtık git hosting hedefleyen bir proje
    • Ama çoğu geliştirici imza anahtarlarını yönetmeyi beceremiyor
    • Bu yüzden Tangled ya da ForgeFed gibi federasyon protokolleri Forgejo’ya entegre ediliyor
    • git-bug da ilginç bir yaklaşım. Henüz denemedim ama potansiyelli görünüyor