▲

GitHub에서 Codeberg로: 나의 경험

 (eldred.fr)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 개인 프로젝트와 웹사이트를 GitHub에서 Codeberg로 이전한 과정과 결과를 구체적으로 설명
  • Forgejo의 “migrate from GitHub” 기능을 이용해 저장소, 이슈, PR, 위키, 릴리스를 완전하게 이전
  • 링크 재지정과 GitHub 저장소 스텁 처리를 자동화 스크립트로 수행해 이전 사실을 명확히 표시
  • CI/CD 이전에서는 Codeberg의 Forgejo Actions를 활용하고, 환경 제약에 맞춰 경량화된 워크플로를 구성
  • 웹사이트는 git-pages와 Grebedoc을 이용해 무중단으로 이전, 전체 마이그레이션을 주말 내 완료

마이그레이션 개요

  • GitHub Pages에서 호스팅하던 사이트와 45개의 저장소를 Codeberg로 이전
    • 단순 클릭으로 끝나지 않고 여러 단계의 수작업이 필요했음
    • 전체 과정은 주말 동안 완료되었으며, 불편함 없이 진행됨
  • 이 과정을 통해 다른 개발자들도 쉽게 이전할 수 있음을 보여주려는 목적

1단계: 저장소 이전

  • Codeberg는 Forgejo 기반으로, “migrate from GitHub” 기능을 제공
    • GitHub에서 Personal Access Token(PAT) 을 생성해 이슈 등 메타데이터를 함께 가져올 수 있음
    • GitHub API의 rate limit 때문에 동시에 여러 저장소를 가져오면 실패할 수 있었음
  • 이슈, PR, 위키, 릴리스가 완벽히 이전되어 GitHub 참조가 불필요해짐

2단계: 링크 재지정

  • 로컬 저장소 내의 GitHub 링크를 Codeberg 주소로 일괄 변환
    • sed와 find 명령어를 이용해 텍스트 기반으로 자동 치환
  • 각 저장소의 git remote URL도 Codeberg로 변경 후 모든 저장소에 푸시

3단계: GitHub 저장소 스텁 처리

  • GitHub 저장소에 이전 공지용 README를 추가하고, 설명과 홈페이지 링크를 Codeberg로 수정
    • 자동화 스크립트를 작성해 여러 저장소에 일괄 적용
    • gh repo archive 명령으로 저장소를 아카이브 처리

4단계: CI/CD 이전

  • Codeberg의 CI 문서에서 에너지 소비 최소화 원칙을 강조
    • 이에 따라 CI가 꼭 필요한 프로젝트(웹사이트, 문서 빌드 등)만 유지
  • Codeberg는 Woodpecker와 Forgejo Actions 두 가지 CI를 제공
    • GitHub Actions와 유사한 Forgejo Actions를 선택
  • 주요 차이점
    • 대부분의 Actions가 그대로 작동
    • Linux 전용 러너만 제공, macOS·Windows는 비제공
    • 설치된 소프트웨어가 적고 자원이 제한적
    • lazy runners를 사용하면 부하 분산과 친환경적 실행 가능
  • CI 성능 향상을 위해 LaTeX 사전 설치 Docker 이미지를 사용했으나 버전 문제로 기본 Ubuntu 이미지로 복귀

5단계: 웹사이트 재호스팅

  • GitHub Pages에서 운영하던 사이트를 Codeberg Pages로 옮기려 했으나, 해당 기능이 유지보수 모드 상태
    • 복잡성과 성능 문제로 업데이트가 지연 중
  • 대안으로 git-pages와 Grebedoc을 발견해 사용
    • DNS 변경 전 업로드 지원으로 무중단 전환 가능
    • 서버 측 리디렉션과 커스텀 헤더 지원
    • 기존 링크(eldred.fr/fortISSimO)를 유지하면서 이전 완료
  • Codeberg는 향후 git-pages로 점진적 이전을 계획 중
  • GitHub Pages보다 만족도가 높아 git-pages 개발자 Patreon 후원 참여

시간 소요

  • 저장소 이전(1~3단계): 반나절
  • CI 이전(4단계): 반나절
  • 웹사이트 이전(5단계): 기술 부채 정리 포함 며칠 소요
  • 전체적으로 주말 내 완료, 예상보다 간단한 작업

마이그레이션 이후

  • 웹사이트 기능 이상 없음, GitHub의 master 브랜치만 축소
    • 영구 링크(permalink)는 여전히 작동
  • GitHub 저장소 삭제는 리디렉션 부재로 보류 중
  • GitHub 계정은 타 프로젝트 기여를 위해 유지
  • Codeberg로 옮기며 기여자 수 감소 가능성은 있으나, 일부 사용자가 이미 Codeberg 계정을 생성해 지속 기여 중

감사 인사

  • Catherine ‘whitequark’ : git-pages 및 Grebedoc 운영
  • SERVFAIL network 팀: DNS 제공
  • Codeberg 및 Forgejo 기여자들: 마이그레이션 기반 제공
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 이번 마이그레이션 이야기에서 눈에 띄는 건 기술적인 부분이 아니라, ‘기능 동등성(feature parity)’이 진짜 장애물이 아니라는 점임
    Codeberg는 일상적인 워크플로우에는 충분하지만, GitHub이 쌓아온 네트워크 효과와 관성이 부족함

    • Tangled.org 같은 프로젝트가 이 문제를 일부 해결하려고 함
      Bluesky와 같은 프로토콜을 기반으로 해서, Git이 어디에 호스팅되든 정체성과 연결성이 유지되도록 설계됨
    • 내가 Codeberg에서 겪은 가장 큰 불편은 이슈 검색 기능이 약하다는 점임
      예전에 분명히 본 이슈를 다시 찾기 어려움. 성능은 최근엔 괜찮아졌지만, 수백 개의 이슈가 있는 프로젝트라면 테스트 마이그레이션을 먼저 해보는 게 좋음
    • GitHub에는 방대한 문서와 예시가 있어서, 새로 합류한 사람도 쉽게 적응할 수 있음
      CI/CD 같은 건 팀 전체가 알 필요는 없고, 한 명만 잘 알아도 충분함

  • Codeberg는 Gitea의 포크이고, Gitea는 Gogs의 포크임
    두 포크 모두 기술적 이유보다는 철학적 이유로 시작되었고, Gogs를 만든 Joe Chen이 큰 공을 세웠음

    • 실제로는 Codeberg는 Forgejo 기반의 웹사이트임
      Gitea는 한 개발자가 저장소 권한을 독점해서 포크된 것이고, Forgejo는 Gitea의 상표권을 되찾기 위해 만들어진 포크임
    • 농담이지만, 언젠가 Codeberg 커뮤니티도 사소한 이념 차이로 분열될지도 모른다는 얘기도 나옴

  • Codeberg와 F-Droid를 함께 써본 사람이 있는지 궁금함
    GitHub처럼 자동으로 릴리스를 감지할 수 있는지 알고 싶음

    • F-Droid는 아니지만, Codeberg 지원을 추가하는 프로젝트들이 늘고 있음
      이제 临계점(threshold effect) 에 도달한 듯함

  • 최근 며칠간 여러 프로젝트가 GitHub에서 이탈하는 걸 봤음
    무슨 사건이나 트렌드가 있는지 궁금함

    • GitHub의 가용성 문제, Microsoft의 AI 강제 통합, Azure 이전에 집중하느라 기능 개선이 뒤처진 점 등이 원인일 수 있음
    • Zig의 마이그레이션 발표가 좋은 참고가 됨
    • GitHub이 신뢰 붕괴(trust thermocline) 현상을 겪고 있는 것 같음
      오픈소스 커뮤니티의 불만이 누적되다가 한계점에 도달한 듯함
      Microsoft 전반의 AI·광고화 논란과 Windows 10 지원 종료도 영향을 주는 듯함
      관련 개념은 이 트위터 스레드에서 처음 제시됨
    • 개인적으로는 GitHub의 AI 남용이 지침
      예전의 Rails 기반일 때가 더 나았던 것 같음
    • 이건 일종의 Summer of the Shark 현상처럼 보임
      실제보다 과도하게 주목받는 일시적 현상일 수도 있음

  • GitHub 대안 중 소규모 팀이나 개인 개발자에게 적합한 게 있는지 궁금함
    Codeberg는 FOSS 중심이라서 상업적 용도엔 맞지 않아 보임

    • Codeberg의 기반인 Forgejo를 직접 호스팅할 수 있음
      GitLab은 기능이 많지만 유지보수가 무거움
      그 외에도 Gitea, Gogs, Phorge 등 다양한 FOSS 포지가 있음
    • GitHub의 핵심은 기술이 아니라 소셜 네트워크임
    • 나는 sourcehut을 선호함
      GitHub UI를 복제하지 않고, 로컬처럼 빠른 즉각적인 인터페이스가 마음에 듦
    • 특별한 이유가 없다면 GitHub을 계속 쓰는 게 합리적임
      “Microsoft가 싫다”는 이유만으로 옮길 필요는 없음
    • 개인용으로는 Migadu 같은 저비용 프라이빗 호스팅을 찾고 있었지만 마땅한 게 없었음
      결국 Codeberg에 새 프로젝트를 올리고, 일부는 GCP에 프라이빗 미러로 유지 중임
      관련해서 Ask HN 스레드를 올렸지만 반응은 없었음

  • eldred.fr의 블로그 글을 보면 저자의 이유는 합리적이지만, 사용자 입장에서는 체감 개선이 거의 없음
    Codeberg를 써보니

    • “봇이 아닌지 확인 중”이라는 애니메이션 검증 화면이 자주 뜸
    • GitHub 로그인 버튼이 작게 숨겨져 있음
    • UI는 GitHub과 거의 동일하고, README가 아래쪽에 있어서 불편함
      예: https://codeberg.org/dnkl/foot
      README를 메인 페이지로 두는 게 더 나을 듯함
    • 결국 차별화 없는 복제 전략은 매력적이지 않음
    • “봇 검증”은 Anubis라는 오픈 솔루션을 사용함
      유료 버전에서는 이미지 커스터마이징도 가능함
    • GitHub을 그대로 따라가는 건 사용자 익숙함을 위한 선택임
      너무 다르게 만들면 오히려 반발이 큼
      GitHub 로그인 버튼을 숨긴 건 커뮤니티 중심의 결정이며, 원하면 PR로 제안할 수도 있음
    • 이런 문제들은 오히려 서비스의 깊은 문제를 드러내는 신호일 수도 있음
    • 나는 GitHub의 AI 학습 논란과 중앙집중화에 지쳐서 Codeberg로 옮겼음
      GitHub과 동일한 기능을 갖추되, 윤리적 대안을 찾는 게 목적이었음

  • GitHub에서 AI 스캔이 문제되지 않는다면, 비정치적 이유로 옮길 필요가 있는지 궁금함

    • 최근 GitHub의 가용성 저하가 있었지만, 불편함의 정도는 개인 판단에 달림

  • Codeberg가 무료 CI 러너를 제공하는지 궁금함
    GitHub은 연간 1억 달러 이상을 CI에 쓰는 것으로 추정됨

    • Codeberg 문서(docs.codeberg.org/ci)에 따르면, 용량이 제한되어 있고 요청 후 승인을 받아야 함
    • 개인적으로는 Woodpecker 인스턴스를 Codeberg와 함께 써서 잘 작동 중임
    • Codeberg는 CI/CD의 에너지 비용을 강조함
      하지만 환경 비용을 언급하는 건 오히려 사용자 참여를 꺼리게 만들 수 있음
      기술자에게는 성능 최적화 문제로 접근하는 게 더 효과적임
    • 이런 CI 인프라가 바로 GitHub의 진입장벽(moat) 이라고 생각함

  • Codeberg가 예전에 스팸 사건을 “극우 혐오 캠페인”으로 과장하며 자화자찬한 걸 보고 실망했음
    단순히 예방 실패를 인정했으면 됐는데, 정치적 프레임으로 포장함
    관련 링크: 이슈, HN 토론, 블로그 글

    • 이런 태도는 과도한 자기미화로 보임
    • 하지만 인종차별적 단어를 사용한 스팸이라면, Codeberg의 대응은 정당했다고 봄
      그런 이유로 존중을 잃었다면, 문제는 프로젝트가 아니라 그 시각에 있음

  • 나도 한때 Codeberg로 저장소를 옮겼다가 다시 GitHub으로 복귀했음
    GitHub의 여러 기능이 마음에 들진 않지만, Codeberg에는 협업을 끌어당기는 힘이 부족함
    단독 유지보수자로서는 가시성과 네트워크 효과가 절실함

답변달기