ย้ายจาก GitHub ไป Codeberg สำหรับคนขี้เกียจ

 (unterwaditzer.net)
1 คะแนน โดย GN⁺ 2026-03-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ขณะย้ายบางโปรเจ็กต์ จาก GitHub ไปยัง Codeberg ผู้เขียนได้สรุปวิธีเริ่มย้ายโดยใช้ความพยายามให้น้อยที่สุด
  • ผ่าน ฟีเจอร์นำเข้าที่เก็บโค้ด ของ Codeberg สามารถย้ายได้ครบทั้ง issue, PR และ release และ UI กับเวิร์กโฟลว์ก็คล้าย GitHub
  • การโฮสต์หน้าเว็บแบบสแตติก สามารถใช้ codeberg.page แทนได้ และยังมีทางเลือกอย่าง grebedoc.dev หรือ statichost.eu
  • ความยากที่สุดคือ การตั้งค่าสภาพแวดล้อม CI โดยต้องยอมเสีย macOS runner และโควตาการรันฟรีของ GitHub และสามารถใช้ Forgejo Actions หรือ Woodpecker CI แทนได้
  • หลังย้ายแล้ว สามารถคงที่เก็บโค้ดบน GitHub ไว้เป็น อาร์ไคฟ์แบบอ่านอย่างเดียวหรือทำมิเรอร์ เพื่อไม่ตัดขาดจากระบบนิเวศโอเพนซอร์สโดยสิ้นเชิง

กระบวนการย้ายจาก GitHub ไปยัง Codeberg

  • อธิบายระดับความยากและความสะดวกของการย้ายจริง โดยอิงจากประสบการณ์ที่เริ่ม ย้ายบางที่เก็บโค้ดจาก GitHub ไป Codeberg
    • แม้จะเคยเลื่อนการย้ายออกไปเพราะคิดว่า Codeberg ยังไม่พร้อมพอ แต่สำหรับบางโปรเจ็กต์ การย้ายอาจง่ายกว่าที่คิด
    • เป้าหมายไม่ใช่การตั้งค่าที่สมบูรณ์แบบ แต่คือการหาวิธี เริ่มย้ายได้ง่ายที่สุด

  • การย้ายที่เก็บโค้ดและ issue

    • Codeberg มีฟีเจอร์ นำเข้าที่เก็บโค้ดจาก GitHub (import) และสามารถย้าย issue, PR, release และ artifact ที่เกี่ยวข้องได้พร้อมกัน
      • ระหว่างกระบวนการนี้ หมายเลข issue, label และข้อมูลผู้เขียน จะยังคงเดิม
      • UI ของ Codeberg แทบจะเหมือน GitHub และให้ประสบการณ์ที่ง่ายกว่าขั้นตอนซับซ้อนที่มักต้องใช้เมื่อย้ายจาก issue tracker อื่นมายัง GitHub มาก

  • การโฮสต์หน้าเว็บแบบสแตติก

    • หากเดิมใช้ GitHub Pages ก็สามารถใช้ codeberg.page แทนได้
      • แม้จะไม่มี การรับประกันความพร้อมใช้งานอย่างเป็นทางการ (SLO) แต่ผู้เขียนระบุว่ายังไม่เคยพบ downtime จริง
      • ใช้วิธี push HTML ไปยัง branch ซึ่งมี โครงสร้างคล้าย GitHub Pages
      • อีกทางเลือกคือ grebedoc.dev หรือ statichost.eu

  • ความท้าทายของสภาพแวดล้อม CI (การผสานรวมต่อเนื่อง)

    • ส่วนที่ยากที่สุดระหว่างการย้ายคือ การตั้งค่าสภาพแวดล้อม CI
      • GitHub มี macOS runner ฟรี และ โควตาการรันไม่จำกัดสำหรับที่เก็บโค้ดสาธารณะ แต่บน Codeberg ต้องยอมเสียสิ่งเหล่านี้
      • แนวทางแก้คือใช้ การ cross-compile ตามภาษา และ self-hosting ของ Forgejo Actions runner

    • Forgejo Actions กับ Woodpecker CI

      • บน Codeberg นั้น Woodpecker CI มีความเสถียรกว่า แต่ Forgejo Actions ให้สภาพแวดล้อมที่คุ้นเคยกว่าสำหรับผู้ใช้ GitHub Actions
      • ทั้ง UI และ ไวยากรณ์ YAML แทบเหมือนกัน และเวิร์กโฟลว์ GitHub Actions เดิมส่วนใหญ่ก็ทำงานได้ตามเดิม
      • ตัวอย่างเช่น ส่วนที่ใช้ uses: dtolnay/rust-toolchain ใน GitHub Actions บน Forgejo Actions ก็แค่เปลี่ยนเป็น uses: https://github.com/dtolnay/rust-toolchain
      • ปัจจุบันเอกสารของ Forgejo Actions บน Codeberg ยังไม่อัปเดตล่าสุด และมี PR ที่เกี่ยวข้องอยู่

    • กรณีที่ต้องใช้ macOS runner

      • หากจำเป็นต้องมีการ build บน macOS จริง ๆ ก็สามารถ ใช้ GitHub Actions ต่อไป แล้วทำมิเรอร์ commit จากที่เก็บโค้ดบน Codeberg ไปยัง GitHub ได้
      • สามารถตั้งค่าให้ Forgejo Actions โพล GitHub API เพื่อ ซิงก์สถานะ CI กลับมายัง Codeberg ได้
      • ผู้เขียนยังลองใช้บริการ CI อื่นที่รองรับการ build บน macOS ด้วย แต่การเชื่อมต่อกับ Codeberg ก็ไม่ได้ง่ายไปกว่า GitHub Actions

  • วิธีจัดการกับที่เก็บโค้ดบน GitHub

    • หลังย้ายแล้ว มีการแก้ README ของที่เก็บโค้ดบน GitHub และตั้งเป็นอาร์ไคฟ์
      • สามารถตั้งให้ Codeberg push commit กลับไป GitHub ได้เช่นกัน แต่ในกรณีนั้นผู้ใช้ก็ยังสามารถ เปิด PR และคอมเมนต์ใน issue ได้อยู่
      • บางกรณีมีการ ปิดฟีเจอร์ issue ของที่เก็บโค้ดบน GitHub แต่ถ้าทำแบบนั้น issue ทั้งหมดจะหายไปเป็น 404 และ ไม่สามารถปิด PR ได้
      • ตัวอย่างเช่น ที่เก็บโค้ด libvirt/libvirt ใช้ GitHub Action ที่ปิด PR ทั้งหมดอัตโนมัติ
    • แนวทางแบบนี้อาจส่งผล เชิงลบต่อการโฮสต์เองและระบบนิเวศโอเพนซอร์สโดยรวม
      • ผู้ใช้อาจหมดแรงจูงใจที่จะช่วยปรับปรุงการเพิ่มประสิทธิภาพการ build หรือความถี่ในการดาวน์โหลดไฟล์ release
      • ในช่วงเปลี่ยนผ่าน อาจพิจารณา คงมิเรอร์แบบอ่านอย่างเดียว หรือ ใช้งาน GitHub Pages และ Actions ควบคู่กัน ได้

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-03-27
ความคิดเห็นจาก Hacker News

  • ไม่ได้เกลียด Codeberg เองหรอก แต่ก็ยัง ไม่ใช่ตัวแทน GitHub แบบครบถ้วน
    มันมีข้อจำกัดเยอะถ้าจะใช้ลงคลังโค้ดส่วนตัวหรือสคริปต์ทดลอง และ private repository ก็จำกัดที่ 100MB
    อีกทั้งยังโฮสต์เว็บไซต์แบบ GitHub Pages ไม่ได้ด้วย ถ้าจะใช้ในลักษณะนี้ การ self-host Forgejo เองน่าจะเป็นทางเลือกที่ใช้งานได้จริงกว่า
    รายละเอียดที่เกี่ยวข้องสรุปไว้ดีใน Codeberg FAQ

    • บน Codeberg ก็โฮสต์เว็บไซต์ได้ผ่านฟีเจอร์ Codeberg Pages
    • ฉันก็รันเว็บไซต์ของตัวเองบน Codeberg Pages อยู่เหมือนกัน ข้อมูลข้างบนไม่ถูกต้อง → เอกสาร Codeberg Pages
    • ผมไม่ค่อยเห็นด้วยกับคำพูดที่ว่า “การรัน git server เองเป็นภาระ” ถ้าต้องการแค่ พื้นที่สำหรับ push โค้ด ก็มีแค่ SSH server ตัวเดียวก็พอแล้ว
    • โปรเจกต์ Code Storage ของ Pierre ก็น่าสนใจในฐานะ git server แบบ API ที่ ลดภาระการดูแลระบบ
    • (ขอโปรโมตนิดหนึ่ง) ผมกำลังพัฒนา GitHub ทางเลือกชื่อ Monohub ซึ่งมี private repository ให้โดยค่าเริ่มต้นและรองรับ PR ด้วย ตัวอย่าง public repository

  • เหตุผลง่าย ๆ ที่ผมเอาโปรเจกต์ OSS ไปไว้บน GitHub ก็เพราะ ชุมชนอยู่ที่นั่น
    ถ้าจะแค่เก็บโค้ด ผมโฮสต์เองตรง ๆ ผ่าน SSH หรือ SFTP

    • ที่ชุมชนยังอยู่แค่บน GitHub ก็เป็นปัญหาแบบ ไก่กับไข่อะไรเกิดก่อนกัน สุดท้ายก็ต้องมีใครสักคนย้ายไปแพลตฟอร์มอื่นก่อน ระบบนิเวศจึงจะค่อย ๆ ย้ายตาม
      ผมลงทุกอย่างไว้แค่ใน Gitea instance ส่วนตัว และไม่ได้สนใจเรื่องดาวหรือการโปรโมต
    • การอยู่บน GitHub ต่อไปก็เป็นแค่ ชุมชน FOSS ที่ยอมรับการพึ่งพาแบบปิด เท่านั้นเอง อันที่จริงนโยบายของ GitHub ก็กำลังผลักคนให้ออกไป
    • บางโปรเจกต์ถึงขั้นร่วมพัฒนาไม่ได้เลยถ้าไม่มีบัญชี GitHub ตัวอย่างเช่น ปัญหา crates.io ก็ยังไม่ถูกแก้มา 10 ปีแล้ว และ Reservoir ของ Lean ก็ยังบังคับว่าต้องมี GitHub stars อย่างน้อย 2 ดาว ดูเหมือนเป็นการ เพิ่มการผูกติดกับ Microsoft
    • GitHub ให้ CI resources ฟรีมาเยอะมาก โดยเฉพาะ macOS runner ที่แทบไม่มีตัวแทนได้ เลยทำให้ทดสอบได้ในหลายสภาพแวดล้อม
    • ผมเองก็เริ่ม โฮสต์ Git บน home server เพื่อจะออกจาก GitHub แต่ความ โดปามีน ตอน push commit แบบเมื่อก่อนมันหายไปแล้ว รู้สึกว่าโอเพนซอร์สพอถูกทำให้เป็นเชิงพาณิชย์แล้วเสน่ห์ก็น้อยลง

  • ผมใช้ Forgejo แบบ self-host จัดการโปรเจกต์ส่วนตัวทั้งหมดอยู่ และไม่คิดถึง GitHub เลย
    ยังจำกัดการเข้าถึงด้วย Tailscale เพื่อ บล็อก AI crawler ได้ด้วย

    • ผมก็รัน Forgejo เองมาหลายปีแล้ว เขียน คู่มือติดตั้ง ไว้ด้วย และช่วงหลังก็ย้ายไปใช้ Raspberry Pi 2 เครื่อง บน Hetzner เร็วและเสถียรกว่า GitHub อีก
    • เมื่อก่อนผมใช้ GitLab แต่ Forgejo เบากว่ามากเพราะเป็น Go single binary เลยกินทรัพยากรน้อย รันด้วย Docker ก็ง่าย และยังสนุกตรงที่แก้โค้ดฟีเจอร์เองได้
    • ตอนที่ GitHub บล็อกการสร้าง agent account ผมก็ติดตั้ง Forgejo แล้วใช้เวลาแค่ 15 นาทีเพิ่มฟีเจอร์ “ซ่อนไฟล์ที่ Viewed แล้ว” ในการรีวิว PR เองเลย
    • ช่วงหลังโปรเจกต์ OSS ขนาดใหญ่หลายตัวเริ่มย้ายไป Forgejo ผมก็ย้ายตาม และจนถึงตอนนี้ก็ พอใจมาก
    • ผมก็ติดตั้ง Forgejo runner ด้วย Docker เพื่อรัน CI เหมือนกัน และมี registry ในตัวสำหรับปล่อยแอปเป็น Docker image

  • ต่อไปการประเมิน GitHub ทางเลือกน่าจะยิ่งสำคัญขึ้น
    แต่ GitHub ได้สร้าง มาตรฐานด้าน CI และ multi-architecture build ไปแล้ว ทำให้ทางเลือกที่ขับเคลื่อนโดยชุมชนแข่งได้ยาก

    • CI ไม่จำเป็นต้องผูกกับ GitHub เสมอไป จริง ๆ แล้ว CI ส่วนใหญ่ก็เป็นแค่ ตัวรันคำสั่ง เท่านั้นเอง สำหรับทีมเล็ก ๆ จะไม่มี CI เลยก็ยังไหว
    • ผมไม่เข้าใจว่าทำไมการรัน CI เองถึงถูกมองว่าไม่สมเหตุสมผล แยก repo กับ CI ออกจากกัน ก็ไม่ได้มีปัญหาอะไร
    • สำหรับผม สิ่งสำคัญกว่า CI คือ ประสบการณ์การใช้ PR กับ code review GitHub เองก็ยังมีหลายจุดที่ใช้งานไม่สะดวก และระบบ issue ก็ยังเหมือนติดอยู่เมื่อ 20 ปีก่อน
    • เลเยอร์แบบรวมศูนย์พวกนี้สุดท้ายก็เกิดจาก ความต้องการควบคุม เท่านั้นเอง จริง ๆ แล้วพัฒนาแบบ local-first และกระจายศูนย์ก็มอบประสบการณ์ที่ดีได้เหมือนกัน

  • GitHub ให้หลายอย่างแบบ “ฟรี” ก็จริง แต่สิ่งที่ต้องจ่ายอาจเป็นการถูกเอาไป เก็บข้อมูลและใช้ฝึกโมเดล
    ส่วน Codeberg ไม่รองรับ private repository ทำให้แม้แต่จะกัน Copilot ไม่ให้ไล่เก็บ public repository ก็ยังทำไม่ได้
    ตาม Codeberg FAQ ถ้าต้องการ private project ก็แนะนำให้ self-host Forgejo

    • แต่คลังของผมบน Codeberg ตั้งเป็น private อยู่เหมือนกัน ดังนั้นคงไม่ใช่ว่าทำไม่ได้เลย

  • บริษัทของเราได้ย้ายจาก GitHub ไปเป็น GitLab แบบ self-host เต็มตัวแล้ว
    วางไว้หลัง Tailscale เลยไม่ต้องปวดหัวกับ SSO และรัน CI runner บน EKS กับ GPU cluster ถ้าใครกำลังคิดจะย้ายแบบคล้าย ๆ กัน ผมน่าจะช่วยได้

    • อยากรู้ว่าได้พิจารณา Forgejo ด้วยไหม GitLab เด่นเรื่อง CI/CD ระดับองค์กร แต่ถ้าเป็นโปรเจกต์เล็ก ๆ Forgejo น่าจะเป็นตัวเลือกที่เบากว่า
    • อยากรู้เหมือนกันว่า GitLab แบบ self-host รองรับฟีเจอร์อย่าง automatic user provisioning (SCIM) หรือเปล่า

  • การพูดแค่ว่า “มาแทน GitHub กันเถอะ” ไม่ค่อยมีความหมาย ต้องมี นิสัยการใช้งานใหม่และคุณค่าที่นำเสนอใหม่
    เหมือนที่ GitHub เคยมาแทน SourceForge แพลตฟอร์มรุ่นถัดไปจะต้อง เชื่อมการเขียนโค้ดกับการทำงานร่วมกันแบบเรียลไทม์
    เช่นอาจกลายเป็นโครงสร้างแบบ Google Docs ที่ ทุก prompt สร้าง commit ได้เลย

    • แต่เรื่อง ภูมิรัฐศาสตร์ ก็มีผลมากเช่นกัน หลายพื้นที่อย่างยุโรปกำลังเคลื่อนไหวเพื่อลดการพึ่งพาเทคโนโลยีสหรัฐฯ
    • ช่วงหลังจาก ประเด็นถกเถียงเรื่อง Copilot ความเชื่อใจก็สั่นคลอน จึงเริ่มมีแนวโน้มอยากออกจาก GitHub
    • สำหรับผม สิ่งสำคัญไม่ใช่แค่ฟีเจอร์ แต่คือ availability (uptime) ตอนนี้ GitHub เหมือนยังไม่ถึงระดับ 99% ด้วยซ้ำ

  • Codeberg ฟังดูเป็นอุดมคติ แต่ในความเป็นจริง ปัญหาเรื่องเสถียรภาพ ยังใหญ่
    เพราะรันโดยไม่ใช้ Cloudflare จึง เปราะบางต่อ DDoS และมี downtime บ่อย ระหว่างพัฒนาแล้วเข้า remote repository ไม่ได้มันน่าหงุดหงิดมาก

    • ผมใช้ GitHub หรือ Codeberg แค่เป็นที่ แชร์โค้ดแบบ asynchronous เท่านั้น ต่อให้ remote ล่มก็ยังต้องทำงานต่อจาก local ได้
    • ผมเองก็ไม่ชอบ Cloudflare แต่ในโลกความจริงมันแทบจำเป็นสำหรับ ป้องกัน bot traffic และการโจมตี บริการทางเลือกกลับโดนบล็อกหรือไม่เสถียรบ่อยกว่า ทำให้รู้สึกชัดเลยว่าหลักการกับความจริงมันห่างกันมาก
    • ถ้าดู การติดตามสถานะการทำงาน ของ GitHub ช่วง 90 วันที่ผ่านมาอยู่แค่ราว 90% เอง กลับกลายเป็นว่า Codeberg เสถียรกว่าด้วยซ้ำ
    • git server ส่วนตัวของผมเองก็ช้าลงเพราะโดน AI crawler scraping แบบไม่เลือกหน้า สุดท้ายเลยต้องบล็อก IP ของบริษัทใหญ่ ๆ หมด
    • แก่นของ git คือ ความกระจายศูนย์ ต่อให้ remote ล่ม local ก็ต้องยังมีเวอร์ชันล่าสุดอยู่

  • แทบไม่ได้ใช้ GitHub เลยตั้งแต่ Microsoft เข้าซื้อไป ผมกลับชอบ workflow แบบอิงอีเมลที่เรียบง่ายของ Sourcehut มากกว่า
    และคิดว่า CI ถ้าจะให้พอก็แค่เป็นแบบ ใช้คำสั่งที่รันจาก local ได้ ก็พอ

  • repository โค้ดโดยเนื้อแท้แล้วควรเป็น โครงสร้างแบบกระจายศูนย์และเฟเดอเรต
    ด้วย ระบบลายเซ็นเชิงเข้ารหัสของ git (GPG/SSH) เราจึงแยกความน่าเชื่อถือของ repository ออกจากความน่าเชื่อถือของ commit ได้
    ส่วนกลางควรมีแค่ key server กับการจัดการ namespace ที่เหลือควรกระจายออกไป

    • Radicle ก็คือโปรเจกต์ที่ตั้งเป้าไปทาง git hosting แบบกระจายศูนย์ ลักษณะนี้พอดี
    • แต่ในความเป็นจริง นักพัฒนาส่วนใหญ่ จัดการ signing key กันไม่ค่อยได้ดีนัก
    • ด้วยเหตุนี้ protocol แบบเฟเดอเรตอย่าง Tangled หรือ ForgeFed จึงกำลังถูกผนวกเข้า Forgejo
    • git-bug ก็เป็นแนวทางที่น่าสนใจ ยังไม่ได้ลองใช้ แต่ดูมีศักยภาพ