Dual-Push, Pull Mirror, dan Aturan Main Forgejo+GitHub

Saya buka terminal, ketik ritual yang sudah dibiasakan: git push origin main && git push forgejo main. Dua host, satu repo, tiap commit. Ritual ini jalan mulus sampai saya membaca rekomendasi yang beredar: kalau GitHub tetap jadi host utama, pasang saja pull mirror di Forgejo, biarkan yang mengurus sinkronisasi. Saya hampir ikut. Rekomendasi itu memang masuk akal untuk kebanyakan kasus, dan dokumen resminya jelas ^[1]. Baru satu hal yang bikin saya mundur: branch backup/pre-rewrite-20260911 berukuran 631 MB di Forgejo saya tidak pernah ada di GitHub. Pull mirror bekerja dengan mengikuti upstream secara persis, dan justru pola yang "paling direkomendasikan" itulah yang akan membuang branch itu tanpa suara.

Aturan main pull mirror

Pull mirror di Forgejo hanya bisa dibuat pada saat repo dibuat: lewat New Migration dengan centang "This repository will be a mirror". Repo biasa yang sudah ada tidak bisa dikonversi jadi mirror, dan repo mirror jadi read-only ^[1]. Sinkronisasi berjalan periodik, default-nya 8 jam dengan batas minimum 10 menit ^[5], plus tombol Synchronize Now kalau tidak sabar ^[1].

Sifat "mengikuti upstream secara persis" itu pedang bermata dua. Bagi repo yang isinya sama persis dengan GitHub, ini backup yang ringan dan disiplin. Tapi mirror tidak tahu mana branch lokal yang "berharga". Yang tidak ada di upstream, hilang dari hasil mirror. Data superset tidak bisa lewat jalur ini.

Push mirror dan batasnya

Arah sebaliknya, push mirror dari Forgejo ke GitHub, punya peringatan resmi: selalu force-push dan menimpa isi remote ^[1]. Tanpa Branch Filter, Forgejo menjalankan git push --mirror yang mengirim semua branch ^[1]. Di sisi GitHub, fitur push policy (masih public preview) bisa membatasi jumlah branch dan tag yang boleh berubah dalam satu push, dan policy ini memblokir git push --mirror secara eksplisit ^[2]. Kombinasi keduanya berarti push mirror tanpa filter bisa gagal total di repo yang policy-nya ketat.

Bolong lain ada di LFS. LFS lewat SSH push mirror belum diimplementasi di Forgejo, objek LFS tidak ikut termirror ^[1]. Repo yang andalkan LFS dan mirror SSH bisa merasa aman padahal file besarnya tidak pernah pindah.

Kapan dual-push justru pilihan benar

Dari situ saya berhenti mencari pola "terbaik universal". Untuk repo pribadi berisi branch raksasa, dual-push manual lebih jujur: saya yang putar apa yang dikirim ke mana, dan tidak ada proses otomatis yang diam-diam mengurangi data. Kebiasaan ini memang butuh disiplin; satu push gagal harus diulang sebelum commit berikutnya, kalau tidak dua host perlahan menyimpang.

Pola hidup dua forge ini juga bukan hal eksotis. Pemerintah Belanda menjalankan code.overheid.nl sebagai Forgejo self-hosted di infrastruktur SSC-ICT, soft launch 24 April 2026 dan masih pilot bertahap; GitHub mereka diskualifikasi karena proprietary ^[3]. Codeberg menaungi sekitar 678.000 proyek per Agustus 2026, kira-kira dua kali lipat dibanding November sebelumnya, tanpa paket berbayar atau tier enterprise ^[4]. Ekosistemnya cukup matang untuk dipercaya mengelola kode kedua.

Jadi sekarang aturan saya simpel. Repo yang muat dan sama dengan GitHub: pull mirror, ringan dan tidak perlu diurus. Repo superset dengan branch yang tidak mungkin masuk GitHub: dual-push disiplin. Otomatisasi yang "pintar" kalah sama dua ketikan manual yang jujur soal apa yang dikirim kemana.

Sources

1. Forgejo Docs, Repository Mirrors (diakses 12 September 2026)
2. GitHub Docs, Managing the push policy for your repository (diakses 12 September 2026)
3. It's FOSS, The Netherlands is Quietly Building Its Own GitHub Replacement (diakses 12 September 2026)
4. Code To Cloud, Codeberg: The Non-Profit GitHub Alternative (diakses 12 September 2026)
5. Forgejo Docs, Configuration Cheat Sheet (diakses 12 September 2026)