GitHub से Codeberg पर माइग्रेट करना: आलसी लोगों के लिए एक तरीका

 (unterwaditzer.net)
1 पॉइंट द्वारा GN⁺ 2026-03-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • कुछ प्रोजेक्ट्स को GitHub से Codeberg पर ले जाते हुए, कम-से-कम मेहनत में माइग्रेशन शुरू करने का तरीका संक्षेप में बताया गया है
  • Codeberg की repository import feature के जरिए issues, PRs, और releases समेत पूरा माइग्रेशन संभव है, और UI तथा workflow, GitHub से मिलते-जुलते हैं
  • static page hosting के लिए codeberg.page का विकल्प इस्तेमाल किया जा सकता है, और grebedoc.dev या statichost.eu जैसे विकल्प भी मौजूद हैं
  • सबसे बड़ी कठिनाई CI environment सेटअप है, क्योंकि GitHub के macOS runners और free execution quota को छोड़ना पड़ता है; इसके बदले Forgejo Actions या Woodpecker CI इस्तेमाल किए जा सकते हैं
  • माइग्रेशन के बाद GitHub repository को read-only archive की तरह रखा जा सकता है या mirror किया जा सकता है, ताकि open source ecosystem से जुड़ाव पूरी तरह न टूटे

GitHub से Codeberg पर माइग्रेशन की प्रक्रिया

  • कुछ repositories को GitHub से Codeberg पर माइग्रेट करना शुरू करने के अनुभव के आधार पर, वास्तविक migration process की कठिनाई और सुविधा का वर्णन किया गया है
    • अब तक यह सोचकर टालते रहे कि Codeberg अभी पर्याप्त रूप से तैयार नहीं है, लेकिन project के अनुसार migration उम्मीद से कहीं आसान हो सकता है
    • लक्ष्य एकदम परफेक्ट सेटअप नहीं, बल्कि माइग्रेशन शुरू करने का सबसे आसान तरीका ढूँढना है

  • repository और issue migration

    • Codeberg, GitHub repository import feature देता है, जिसके जरिए issues, PRs, releases और उनके artifacts भी साथ में माइग्रेट किए जा सकते हैं
      • इस प्रक्रिया में issue numbers, labels, और author information जस-का-तस बने रहते हैं
      • Codeberg का UI लगभग GitHub जैसा ही है, और किसी दूसरे issue tracker से GitHub पर जाने में लगने वाली जटिल प्रक्रिया की तुलना में यह कहीं अधिक सरल अनुभव देता है

  • static page hosting

    • अगर आप GitHub Pages इस्तेमाल कर रहे थे, तो उसके विकल्प के रूप में codeberg.page इस्तेमाल किया जा सकता है
      • आधिकारिक availability guarantee (SLO) नहीं है, लेकिन व्यवहार में downtime का अनुभव नहीं हुआ, ऐसा बताया गया है
      • HTML को branch में push करने के तरीके पर आधारित है, यानी GitHub Pages जैसी संरचना
      • विकल्प के तौर पर grebedoc.dev या statichost.eu भी इस्तेमाल किए जा सकते हैं

  • CI (continuous integration) environment की चुनौतियाँ

    • migration के दौरान सबसे मुश्किल हिस्सा CI environment सेटअप है
      • GitHub free macOS runners और public repositories के लिए unlimited execution quota देता है, लेकिन Codeberg पर यह छोड़ना पड़ता है
      • समाधान के रूप में language-specific cross compilation और Forgejo Actions runners की self-hosting का उपयोग किया जा सकता है

    • Forgejo Actions vs Woodpecker CI

      • Codeberg पर Woodpecker CI ज़्यादा स्थिर है, लेकिन Forgejo Actions, GitHub Actions उपयोगकर्ताओं के लिए अधिक परिचित अनुभव देता है
      • UI और YAML syntax लगभग एक जैसे हैं, और मौजूदा GitHub Actions workflows में से अधिकांश बिना बदलाव के चल जाते हैं
      • उदाहरण के लिए, GitHub Actions में uses: dtolnay/rust-toolchain इस्तेमाल किया गया हो, तो Forgejo Actions में उसे uses: https://github.com/dtolnay/rust-toolchain में बदलना होगा
      • फिलहाल Codeberg का Forgejo Actions documentation अप-टू-डेट नहीं है, और इस संबंध में एक PR मौजूद है

    • जब macOS runners की ज़रूरत हो

      • अगर macOS build वास्तव में ज़रूरी है, तो GitHub Actions का उपयोग जारी रखा जा सकता है, और Codeberg repository से GitHub पर commits mirror किए जा सकते हैं
      • Forgejo Actions को GitHub API poll करने और CI status को Codeberg के साथ sync करने के लिए कॉन्फ़िगर किया जा सकता है
      • macOS builds देने वाली दूसरी CI services भी आज़माई गईं, लेकिन Codeberg के साथ उनका integration, GitHub Actions जितना सरल नहीं था

  • GitHub repository को कैसे संभालें

    • migration के बाद GitHub repository में README बदलकर उसे archive किया जा सकता है
      • Codeberg से GitHub पर commits push करने के लिए सेटअप किया जा सकता है, लेकिन इस स्थिति में उपयोगकर्ता अब भी PR बना सकते हैं और issue comments छोड़ सकते हैं
      • कुछ लोग GitHub repository की issues feature disable कर देते हैं, लेकिन तब सभी issues 404 में गायब हो जाते हैं और PRs को disable नहीं किया जा सकता
      • उदाहरण के तौर पर libvirt/libvirt repository सभी PRs को अपने-आप बंद करने वाला GitHub Action इस्तेमाल करती है
    • इस तरह का तरीका self-hosting और पूरे open source ecosystem पर नकारात्मक असर डाल सकता है
      • उपयोगकर्ताओं की build optimization या release files download frequency सुधारने की प्रेरणा कम हो सकती है
      • संक्रमण काल में read-only mirror बनाए रखना या GitHub Pages और Actions को साथ में इस्तेमाल करना भी एक विकल्प हो सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-27
Hacker News की राय

  • मुझे Codeberg से खुद कोई दिक्कत नहीं है, लेकिन यह GitHub का पूरा विकल्प नहीं है
    व्यक्तिगत code repository या experimental scripts अपलोड करने में कई सीमाएँ हैं, और private repository 100MB तक सीमित है
    GitHub Pages की तरह homepage host भी नहीं किया जा सकता। ऐसे उपयोग के लिए Forgejo को self-host करना एक व्यावहारिक विकल्प है
    इससे जुड़ी जानकारी Codeberg FAQ में अच्छी तरह दी गई है

    • Codeberg में भी Codeberg Pages फीचर के ज़रिए homepage host किया जा सकता है
    • मैं भी अपनी website को Codeberg Pages पर चला रहा हूँ। ऊपर दी गई जानकारी गलत है → Codeberg Pages दस्तावेज़
    • “खुद का git server चलाना बोझिल है” इस बात से सहमत होना मुश्किल है। अगर सिर्फ code push करने की जगह चाहिए, तो एक SSH server ही काफ़ी है
    • Pierre द्वारा बनाया गया Code Storage प्रोजेक्ट ऐसे operational overhead को कम करने वाले API-आधारित git server के रूप में दिलचस्प है
    • (थोड़ा प्रचार भी) मैं Monohub नाम का GitHub विकल्प बना रहा हूँ। इसमें private repository default रूप से मिलती है, और PR भी supported है। public repository उदाहरण

  • मैं OSS project GitHub पर इसलिए डालता हूँ क्योंकि community वहीं है
    अगर सिर्फ code अपलोड करना हो, तो मैं सीधे SSH या SFTP से host करता हूँ

    • community का सिर्फ GitHub पर रहना एक मुर्गी-अंडा समस्या है। आखिर किसी को पहले किसी दूसरे platform पर जाना होगा, तभी ecosystem आगे बढ़ेगा
      मैं तो सिर्फ अपने personal Gitea instance पर डालता हूँ, और stars या promotion की परवाह नहीं करता
    • GitHub पर बने रहना बस closed dependency को स्वीकार करने वाली FOSS community है। उल्टा GitHub की नीतियाँ लोगों को दूर धकेल रही हैं
    • कुछ projects में GitHub account के बिना योगदान करना भी संभव नहीं है। उदाहरण के लिए crates.io issue 10 साल से unresolved है, और Lean का Reservoir GitHub पर कम से कम 2 stars माँगता है। यह Microsoft dependency को मज़बूत करने जैसा लगता है
    • GitHub मुफ़्त में बहुत सारे CI resources देता है। खासकर macOS runner का लगभग कोई विकल्प नहीं है। इसी वजह से कई environments में testing संभव हो पाती है
    • मैंने भी GitHub से दूर जाने के लिए home server पर Git hosting शुरू की, लेकिन पहले जैसा commit push करने का dopamine अब नहीं रहा। open source के commercial होने से उसका आकर्षण कम हो गया है

  • मैं Forgejo self-hosting से अपने सारे personal projects संभाल रहा हूँ। GitHub बिल्कुल याद नहीं आता
    Tailscale से access सीमित करके AI crawler block भी किए जा सकते हैं

    • मैं भी कई सालों से Forgejo खुद चला रहा हूँ। installation tutorial भी लिखा था, और हाल ही में Hetzner पर 2 Raspberry Pi में migrate किया है। GitHub से तेज़ और ज़्यादा stable है
    • पहले GitLab इस्तेमाल करता था, लेकिन Forgejo कहीं ज़्यादा हल्का Go single binary है, इसलिए resource consumption कम है। Docker से इसे आसानी से चलाया जा सकता है, और features को खुद hack करने का मज़ा भी है
    • जब GitHub पर agent account बनाना block हो गया था, तब मैंने Forgejo install किया, और 15 मिनट में PR review में “Viewed file छिपाने” वाला feature खुद जोड़ दिया
    • हाल में बड़े OSS projects Forgejo पर जा रहे थे, तो मैं भी चला गया, और अब तक बहुत संतुष्ट हूँ
    • मैं Docker से Forgejo runner भी install करके CI चलाता हूँ। इसका अपना registry है, इसलिए app को Docker image के रूप में deploy करता हूँ

  • आगे GitHub विकल्पों का मूल्यांकन करना और महत्वपूर्ण होता जाएगा
    लेकिन GitHub ने CI और multi-architecture build का standard जैसा बना दिया है, इसलिए community-driven विकल्पों के लिए प्रतिस्पर्धा करना मुश्किल है

    • CI का GitHub पर निर्भर होना ज़रूरी नहीं है। सच कहें तो ज़्यादातर CI बस simple command executor ही हैं। छोटी teams बिना CI के भी आराम से काम कर सकती हैं
    • मुझे समझ नहीं आता कि CI खुद चलाना अव्यावहारिक क्यों माना जाता है। repository और CI को अलग रखने में भी कोई समस्या नहीं है
    • मेरे लिए CI से ज़्यादा महत्वपूर्ण PR और code review experience है। GitHub में अभी भी कई असुविधाएँ हैं, और इसका issue system तो 20 साल पुराना लगता है
    • ऐसे centralized layer आखिरकार control की इच्छा से ही आते हैं। local-first distributed workflow से भी काफ़ी आनंद लेकर development किया जा सकता है

  • GitHub बहुत कुछ “मुफ़्त” देता है, लेकिन बदले में उसका data collection और training में इस्तेमाल होने की संभावना बहुत अधिक है
    Codeberg private repository support नहीं करता, इसलिए Copilot को public repository scrape करने से रोका भी नहीं जा सकता
    Codeberg FAQ के अनुसार, अगर private project चाहिए तो Forgejo self-hosting की सिफारिश की जाती है

    • लेकिन मेरी Codeberg repository private पर set है। तो यह पूरी तरह असंभव तो नहीं लगता

  • हमारी company ने GitHub से GitLab self-hosting पर पूरी तरह migration कर लिया है
    इसे Tailscale के पीछे रखा है, इसलिए SSO का झंझट नहीं है, और CI runner EKS और GPU cluster पर चलते हैं। ऐसा migration सोच रहे लोगों की मदद कर सकता हूँ

    • क्या आपने Forgejo पर भी विचार किया था? GitLab enterprise-grade CI/CD में मज़बूत है, लेकिन छोटे projects के लिए Forgejo शायद ज़्यादा हल्का विकल्प हो सकता है
    • यह भी जानना चाहूँगा कि self-hosted GitLab में automatic user provisioning (SCIM) जैसी सुविधाएँ support होती हैं या नहीं

  • सिर्फ “GitHub को replace करें” कहना पर्याप्त नहीं है। नई आदतें और value proposition चाहिए
    जिस तरह GitHub ने SourceForge को replace किया था, उसी तरह अगली पीढ़ी के platform को code writing और collaboration को real time में जोड़ना होगा
    उदाहरण के लिए, Google Docs की तरह हर prompt पर commit बन जाने वाली संरचना हो सकती है

    • लेकिन geopolitical reasons भी बड़े हैं। अमेरिकी tech dependency से बचने की कोशिश यूरोप जैसे क्षेत्रों में तेज़ है
    • हाल की Copilot controversy के कारण भरोसा हिला है, और GitHub छोड़ने का रुझान बन रहा है
    • मेरे लिए सिर्फ feature नहीं, बल्कि availability (uptime) ज़्यादा महत्वपूर्ण है। आजकल GitHub 99% तक भी नहीं पहुँचता

  • Codeberg आदर्शवादी लगता है, लेकिन व्यवहार में stability issues काफ़ी हैं
    Cloudflare के बिना चलने की वजह से यह DDoS attack के प्रति संवेदनशील है, और downtime भी काफ़ी होता है। development के दौरान remote repository तक पहुँच न हो तो बहुत निराशा होती है

    • मैं GitHub या Codeberg को सिर्फ asynchronous code sharing के लिए इस्तेमाल करता हूँ। remote बंद हो जाए, तब भी local पर काम संभव होना चाहिए
    • मुझे Cloudflare पसंद नहीं, लेकिन व्यवहारिक रूप से bot traffic और attack defense के लिए यह ज़रूरी लगता है। दूसरे विकल्प तो और भी ज़्यादा block हुए या unstable निकले। सिद्धांत और वास्तविकता के बीच का अंतर साफ़ दिखता है
    • GitHub के uptime monitoring को देखें तो पिछले 90 दिनों में यह लगभग 90% स्तर पर है। उल्टा Codeberg ज़्यादा stable है
    • मेरे personal git server की performance भी AI crawlers की अंधाधुंध scraping से गिर गई थी। आख़िरकार मैंने बड़ी companies के IP block कर दिए
    • git का मूल distributed nature है। remote बंद हो जाए, तब भी local में latest version होना चाहिए

  • Microsoft के अधिग्रहण के बाद से मैं GitHub लगभग इस्तेमाल नहीं करता। Sourcehut का सरल email-आधारित workflow मुझे ज़्यादा पसंद है
    CI भी मेरे हिसाब से बस ऐसा command-based system होना चाहिए जो local पर चल सके

  • code repository मूल रूप से distributed और federated structure होनी चाहिए
    git की cryptographic signing system (GPG/SSH) की वजह से repository trust और commit trust को अलग किया जा सकता है
    केंद्र में सिर्फ key server और namespace management रखें, बाकी सब distributed हो सकता है

    • Radicle ठीक ऐसा ही distributed git hosting बनाने वाला project है
    • लेकिन ज़्यादातर developers signing key management ठीक से नहीं कर पाते
    • इसी कारण Tangled या ForgeFed जैसे federation protocol Forgejo में integrate किए जा रहे हैं
    • git-bug भी एक दिलचस्प तरीका है। अभी इस्तेमाल नहीं किया, लेकिन संभावना दिखती है