▲

GitHub에서 Codeberg로 이전하기, 게으른 사람들을 위한 방법

 (unterwaditzer.net)
1P by GN⁺ 6시간전 | ★ favorite | 댓글 1개
  • 일부 프로젝트를 GitHub에서 Codeberg로 옮기며, 최소한의 노력으로 이전을 시작하는 방법을 정리
  • Codeberg의 저장소 가져오기 기능을 통해 이슈·PR·릴리스까지 포함한 완전한 이전이 가능하며, UI와 워크플로가 GitHub과 유사
  • 정적 페이지 호스팅은 codeberg.page로 대체할 수 있고, grebedoc.dev나 statichost.eu 같은 대안도 존재
  • 가장 큰 어려움은 CI 환경 구축으로, GitHub의 macOS 러너와 무료 실행 용량을 포기해야 하며 Forgejo Actions나 Woodpecker CI로 대체 가능
  • 이전 후에는 GitHub 저장소를 읽기 전용 아카이브로 유지하거나 미러링해, 오픈소스 생태계와의 연결을 완전히 끊지 않는 방식이 제시됨

GitHub에서 Codeberg로의 이전 과정

  • 일부 저장소를 GitHub에서 Codeberg로 이전하기 시작한 경험을 기반으로, 실제 마이그레이션 과정의 난이도와 편의성을 설명
    • Codeberg가 충분히 준비되지 않았다고 생각해 미뤄왔지만, 프로젝트에 따라 이전이 의외로 간단할 수 있음
    • 목표는 완벽한 설정이 아니라 가장 쉽게 이전을 시작할 수 있는 방법을 찾는 것에 있음

  • 저장소 및 이슈 이전

    • Codeberg는 GitHub 저장소 가져오기(import) 기능을 제공하며, 이슈·PR·릴리스와 그 아티팩트를 함께 이전 가능
      • 이 과정에서 이슈 번호, 라벨, 작성자 정보가 그대로 유지됨
      • Codeberg의 UI는 GitHub과 거의 동일하며, 다른 이슈 트래커에서 GitHub로 옮길 때 필요한 복잡한 절차보다 훨씬 간단한 경험 제공

  • 정적 페이지 호스팅

    • GitHub Pages를 사용하던 경우 codeberg.page를 대체로 사용할 수 있음
      • 공식적인 가용성 보장(SLO) 은 없지만, 실제로는 다운타임을 경험하지 않았다고 언급
      • HTML을 브랜치에 푸시하는 방식으로, GitHub Pages와 유사한 구조
      • 대안으로 grebedoc.dev 또는 statichost.eu도 사용 가능

  • CI(지속적 통합) 환경의 어려움

    • 마이그레이션 중 가장 까다로운 부분은 CI 환경 구축
      • GitHub는 무료 macOS 러너와 공개 저장소 무제한 실행 용량을 제공하지만, Codeberg에서는 이를 포기해야 함
      • 해결책으로 언어별 크로스 컴파일과 Forgejo Actions 러너의 셀프 호스팅을 활용 가능

    • Forgejo Actions vs Woodpecker CI

      • Codeberg에서는 Woodpecker CI가 더 안정적이지만, Forgejo Actions가 GitHub Actions 사용자에게 더 익숙한 환경 제공
      • UI와 YAML 문법이 거의 동일하며, 기존 GitHub Actions 워크플로 대부분이 그대로 작동
      • 예시로 GitHub Actions에서 uses: dtolnay/rust-toolchain을 사용하던 부분을 Forgejo Actions에서는 uses: https://github.com/dtolnay/rust-toolchain으로 변경하면 됨
      • 현재 Codeberg의 Forgejo Actions 문서는 최신 상태가 아니며, 관련 PR이 존재함

    • macOS 러너가 필요한 경우

      • macOS 빌드가 꼭 필요하다면 GitHub Actions을 계속 사용하고, Codeberg 저장소에서 GitHub로 커밋을 미러링하는 방법 가능
      • Forgejo Actions가 GitHub API를 폴링하여 CI 상태를 Codeberg로 동기화하도록 설정 가능
      • 다른 macOS 빌드 제공 CI 서비스도 시도했으나, Codeberg와의 통합이 GitHub Actions보다 단순하지 않음

  • GitHub 저장소의 처리 방식

    • 이전 후 GitHub 저장소는 README를 수정하고 아카이브 처리
      • Codeberg에서 GitHub로 커밋을 푸시하도록 설정할 수도 있지만, 이 경우 사용자가 여전히 PR 작성 및 이슈 코멘트 가능
      • 일부는 GitHub 저장소의 이슈 기능을 비활성화하지만, 이 경우 모든 이슈가 404로 사라지고 PR은 비활성화 불가
      • 예시로 libvirt/libvirt 저장소는 모든 PR을 자동으로 닫는 GitHub Action을 사용
    • 이러한 접근은 자체 호스팅 및 오픈소스 생태계 전반에 부정적 영향을 줄 수 있음
      • 사용자가 빌드 최적화나 릴리스 파일 다운로드 빈도를 개선할 동기를 잃게 됨
      • 전환기 동안에는 읽기 전용 미러 유지나 GitHub Pages·Actions 병행 사용도 고려 가능
▲
GN⁺ 6시간전  [-]
Hacker News 의견들

  • Codeberg 자체는 싫지 않지만, GitHub의 완전한 대체재는 아님
    개인용 코드 저장소나 실험용 스크립트를 올리기엔 제약이 많고, 비공개 저장소는 100MB로 제한되어 있음
    GitHub Pages처럼 홈페이지를 호스팅할 수도 없음. 이런 용도라면 직접 Forgejo를 셀프호스팅하는 게 현실적인 대안임
    관련 내용은 Codeberg FAQ에 잘 정리되어 있음

    • Codeberg에서도 Codeberg Pages 기능을 통해 홈페이지를 호스팅할 수 있음
    • 나도 내 웹사이트를 Codeberg Pages에 올려서 운영 중임. 위 정보는 잘못된 내용임 → Codeberg Pages 문서
    • “직접 git 서버를 돌리는 건 부담스럽다”는 말에 동의하기 어려움. 단순히 코드를 푸시할 공간만 원한다면 SSH 서버 하나면 충분함
    • Pierre가 만든 Code Storage 프로젝트가 이런 운영 부담을 줄이는 API형 git 서버로 흥미로움
    • (홍보 겸) 나는 Monohub라는 GitHub 대안을 개발 중임. 비공개 저장소를 기본 제공하고, PR도 지원함. 공개 저장소 예시

  • 나는 OSS 프로젝트를 GitHub에 올리는 이유가 단순함 — 커뮤니티가 거기 있기 때문임
    코드만 올릴 거면 SSH나 SFTP로 직접 호스팅함

    • 커뮤니티가 GitHub에만 머무는 건 닭이 먼저냐 달걀이 먼저냐 문제임. 결국 누군가 먼저 다른 플랫폼으로 옮겨야 생태계가 이동함
      나는 내 개인 Gitea 인스턴스에만 올리고, 별이나 홍보엔 신경 쓰지 않음
    • GitHub에 남아 있는 건 폐쇄적 의존성을 받아들이는 FOSS 커뮤니티일 뿐임. 오히려 GitHub의 정책이 사람들을 떠나게 만들고 있음
    • 일부 프로젝트는 GitHub 계정이 없으면 참여조차 불가능함. 예를 들어 crates.io 이슈는 10년째 해결되지 않았고, Lean의 Reservoir는 GitHub 별 2개 이상을 요구함. Microsoft 종속성 강화로 보임
    • GitHub는 무료로 CI 리소스를 많이 제공함. 특히 macOS 러너는 대체제가 거의 없음. 덕분에 다양한 환경에서 테스트 가능함
    • 나도 GitHub에서 벗어나려고 홈서버에 Git 호스팅을 시작했지만, 예전처럼 커밋 푸시할 때의 도파민은 사라졌음. 오픈소스가 상업화되며 매력이 줄어든 느낌임

  • 나는 Forgejo 셀프호스팅으로 모든 개인 프로젝트를 관리 중임. GitHub가 전혀 그립지 않음
    Tailscale로 접근을 제한해 AI 크롤러 차단도 가능함

    • 나도 몇 년째 Forgejo를 직접 운영 중임. 설치 튜토리얼도 작성했고, 최근엔 Hetzner에서 Raspberry Pi 2대로 이전했음. GitHub보다 빠르고 안정적임
    • 예전엔 GitLab을 썼지만, Forgejo는 훨씬 가벼운 Go 단일 바이너리라 리소스 소모가 적음. Docker로 쉽게 돌릴 수 있고, 직접 기능을 해킹하는 재미도 큼
    • GitHub에서 에이전트 계정 생성이 막혔을 때 Forgejo를 설치했는데, 15분 만에 PR 리뷰에서 “Viewed 파일 숨기기” 기능을 직접 추가했음
    • 최근 대형 OSS 프로젝트들이 Forgejo로 이동하면서 나도 따라갔는데, 지금까지 아주 만족스러움
    • 나도 Docker로 Forgejo 러너를 설치해 CI를 돌림. 자체 레지스트리가 있어서 앱을 Docker 이미지로 배포함

  • 앞으로 GitHub 대안을 평가하는 게 점점 중요해질 것 같음
    하지만 GitHub가 CI와 멀티 아키텍처 빌드 표준을 만들어버려서, 커뮤니티 주도의 대체재가 경쟁하기 어려움

    • CI가 꼭 GitHub에 종속될 필요는 없음. 사실 대부분의 CI는 단순한 명령 실행기일 뿐임. 작은 팀이라면 CI 없이도 충분히 운영 가능함
    • CI를 직접 운영하는 게 왜 비합리적인지 모르겠음. 레포와 CI를 분리해도 문제없음
    • 나에게 중요한 건 CI보다 PR과 코드리뷰 경험임. GitHub는 여전히 불편한 부분이 많고, 이슈 시스템도 20년 전 수준임
    • 이런 중앙화된 레이어는 결국 통제 욕구 때문임. 로컬 중심의 분산형 워크플로우로도 충분히 즐겁게 개발할 수 있음

  • GitHub는 많은 걸 “무료”로 제공하지만, 그 대가로 데이터 수집과 학습에 활용될 가능성이 큼
    Codeberg는 비공개 저장소를 지원하지 않아, Copilot이 공개 저장소를 긁어가는 걸 막을 수도 없음
    Codeberg FAQ에 따르면, 비공개 프로젝트가 필요하면 Forgejo 셀프호스팅을 권장함

    • 하지만 내 Codeberg 저장소는 비공개로 설정되어 있음. 완전히 불가능한 건 아닌 듯함

  • 우리 회사는 GitHub에서 GitLab 셀프호스팅으로 완전히 이전했음
    Tailscale 뒤에 두어 SSO 부담이 없고, CI 러너는 EKS와 GPU 클러스터에서 돌림. 비슷한 이전을 고민하는 사람에게 도움 줄 수 있음

    • Forgejo도 고려했는지 궁금함. GitLab은 엔터프라이즈급 CI/CD에 강하지만, 작은 프로젝트엔 Forgejo가 더 가벼운 선택일 듯함
    • 셀프호스팅 GitLab에서 자동 사용자 프로비저닝(SCIM) 같은 기능을 지원하는지도 궁금함

  • 단순히 “GitHub를 대체하자”는 건 의미 없음. 새로운 습관과 가치 제안이 필요함
    GitHub가 SourceForge를 대체했듯, 다음 세대 플랫폼은 코드 작성과 협업을 실시간으로 연결해야 함
    예를 들어 Google Docs처럼 프롬프트마다 커밋이 생성되는 구조가 될 수도 있음

    • 하지만 지정학적 이유도 큼. 미국 기술 의존을 피하려는 움직임이 유럽 등에서 활발함
    • 최근 Copilot 논란으로 신뢰가 흔들리며, GitHub를 떠나려는 흐름이 생김
    • 나에게 중요한 건 단순히 기능이 아니라 가용성(uptime) 임. 요즘 GitHub는 99%도 못 미치는 수준임

  • Codeberg는 이상적이지만, 현실적으로 안정성 문제가 큼
    Cloudflare 없이 운영하다 보니 DDoS 공격에 취약하고, 다운타임이 잦음. 개발 중에 원격 저장소에 접근 못 하면 정말 답답함

    • 나는 GitHub나 Codeberg를 단순히 비동기 코드 공유용으로만 씀. 원격이 죽어도 로컬에서 작업 가능해야 함
    • Cloudflare가 싫지만, 현실적으로는 봇 트래픽과 공격 방어를 위해 필수적임. 대안 서비스들은 오히려 더 자주 막히거나 불안정했음. 원칙과 현실의 괴리를 절실히 느낌
    • GitHub의 가동률 모니터링을 보면 최근 90일간 90% 수준임. 오히려 Codeberg가 더 안정적임
    • 내 개인 git 서버도 AI 크롤러들의 무차별 스크래핑으로 성능이 떨어졌음. 결국 주요 기업 IP를 다 차단함
    • git의 핵심은 분산성임. 원격이 죽어도 로컬에 최신 버전이 있어야 함

  • Microsoft 인수 이후 GitHub를 거의 쓰지 않음. Sourcehut의 단순한 이메일 기반 워크플로우가 오히려 마음에 듦
    CI도 단순히 로컬에서 실행 가능한 명령 기반이면 충분하다고 생각함

  • 코드 저장소는 본질적으로 분산·연합형 구조여야 함
    git의 암호학적 서명 체계(GPG/SSH) 덕분에 저장소 신뢰와 커밋 신뢰를 분리할 수 있음
    중앙에는 키 서버와 네임스페이스 관리만 두고, 나머지는 분산시키면 됨

    • Radicle이 바로 이런 분산형 git 호스팅을 목표로 하는 프로젝트임
    • 하지만 대부분의 개발자는 서명 키 관리를 제대로 하지 못함
    • 이런 이유로 Tangled나 ForgeFed 같은 연합 프로토콜이 Forgejo에 통합되고 있음
    • git-bug도 흥미로운 접근임. 아직 써보진 않았지만 가능성이 있어 보임
답변달기