Gitea 1.25.4에서 Gitea 28.1.0으로 리포지토리를 마이그레이션할 때 발생하는 'nil pointer dereference' panic을 수정하는 방법은?

이 패닉은 Gitea go-sdk v1.2.0(version.go)의 버그로 인해 발생하며, 소스 서버의 버전을 감지하거나 파싱하지 못할 때 크래시가 발생합니다. 이 문제는 go-gitea/gitea PR #39742에서 수정되었으며 28.1.0 이후 릴리스에 포함됩니다. PR #39424에서도 이 패닉을 방지합니다. 업그레이드할 수 있을 때까지의 우회 방법: 1) 'Gitea' 프로바이더 대신 일반 'Git' 마이그레이션 프로바이더를 사용하세요. 정상적으로 완료됩니다(Git 데이터만 복사되며 이슈/PR/메타데이터는 복사되지 않음에 유의하세요). 'certificate signer not trusted' 오류가 발생하면 소스 서버의 CA를 대상 서버의 신뢰할 수 있는 인증서 저장소에 먼저 설치하세요. 2) 가급적이면 아예 마이그레이션하지 마세요. 마이그레이션은 어차피 데이터의 100%를 복사하지 않으므로, 기존 서버의 전체 Gitea 데이터 디렉터리와 데이터베이스를 새 서버로 복사한 후 새 인스턴스를 시작하여 그 자리에서 업그레이드하세요.

v28.1.0에서 `git reflog expire --all`로 인해 발생하는 60–90초의 Gitea 푸시 지연을 어떻게 해결하나요?

PR #39703 또는 해당 백포트가 포함된 Gitea 릴리스로 업그레이드하세요. 이 버전에서는 reflog 만료를 Git의 기본값에 맡깁니다. 업그레이드 후에는 기존 리포지토리에서 오래된 설정 키를 제거하세요. 영향을 받는 bare 리포지토리에 대한 즉각적인 임시 해결 방법: ```bash # 값이 어느 설정 범위(scope)에 있는지 확인 git -C /path/to/owner/repo.git config --show-origin --get-all gc.reflogExpire # Git의 내장 기본값이 사용되도록 해당 값 제거 git -C /path/to/owner/repo.git config --unset gc.reflogExpire ``` 전역으로 설정된 경우: ```bash git config --global --unset gc.reflogExpire ``` 또는 유효한 Git approxidate 값으로 교체하세요: ```bash git -C /path/to/owner/repo.git config gc.reflogExpire '90 days ago' ``` 모든 Gitea 리포지토리에 적용하려면 Docker 볼륨에 맞게 경로를 조정하세요: ```bash find /var/lib/gitea/data/gitea-repositories -type d -name '*.git' -print0 | while IFS= read -r repo; do git -C "$repo" config --unset-all gc.reflogExpire 2>/dev/null || true done ``` 선택적으로 유지보수 시간 동안 누적된 reflog를 일회성으로 정리할 수 있습니다: ```bash git -C /path/to/owner/repo.git reflog expire --all \ --expire='90 days ago' --expire-unreachable='30 days ago' ``` 단독 값 `90`은 Git에서 "90일 전"이 아니라 1990년의 날짜로 파싱되므로, 도달 가능한(reachable) reflog 항목이 만료되지 않습니다. Git 2.54+에서는 push로 트리거되는 자동 유지보수가 `git reflog expire --all`을 포그라운드에서 실행합니다. `core.logAllRefUpdates=true`를 사용하는 트래픽이 많은 bare 리포지토리에서는 수만 개의 `refs/pull/*` reflog를 스캔하는 작업이 `git-receive-pack`을 차단하여 push 후 지연이 발생합니다.

왜 Gitea는 cron.git_gc_repos TIMEOUT을 무시하고 git gc가 너무 오래 실행되도록 내버려 두나요?

이것은 Gitea 1.27.3 및 영향을 받는 `main` 빌드의 버그입니다: `GitGcRepo`는 구성된 타임아웃을 전달받지만 이를 Git 명령에 전달하지 않으므로 `context.DeadlineExceeded`가 적용되지 않습니다. 수정 방법: 1. `GitGcRepo` 타임아웃 처리 수정이 포함된 Gitea 릴리스로 업그레이드하세요. 2. 수정된 릴리스가 없는 경우, 기존 `fsck` 구현과 동일하게 `git gc` 명령 체인에 `.WithTimeout(timeout)`을 추가하여 `services/repository/check.go`를 패치하세요: ```go err := git.NewCommand(ctx, "gc"). WithTimeout(timeout). // <-- 이 부분을 추가 Run(&git.RunOpts{ Dir: repo.Path, }) ``` 정확한 호출 체인에는 `SetDescription` 또는 기타 옵션이 포함될 수 있으며, `Run` 앞에 `.WithTimeout(timeout)`을 추가하세요. 3. Gitea를 다시 빌드하고 재배포한 후 기존 구성을 유지하세요: ```ini [cron.git_gc_repos] TIMEOUT = 8h ``` 패치되지 않은 버전에서의 임시 해결 방법: 자동 GC 작업을 비활성화하고 Git 사용자로 OS `timeout` 명령을 사용하여 GC를 수동으로 실행하세요: ```ini [cron.git_gc_repos] ENABLED = false ``` ```sh sudo -u git timeout 8h git -C /var/lib/gitea/git/repositories/owner/repo.git gc ``` 이전에 실패한 GC가 오래된 `gc.pid` 잠금을 남긴 경우, 잠금 파일을 제거하기 전에 해당 저장소에 대해 실행 중인 `git gc` 프로세스가 없는지 먼저 확인하세요. 무시된 타임아웃 결함 자체가 오래된 잠금 실패의 원인이라고 입증되지는 않았습니다.

Gitea/Forgejo에서 Gitea로 마이그레이션한 후 이슈와 댓글의 작성자가 'Ghost'로 표시되는 이유는 무엇인가요?

이것은 Gitea의 migration downloader(`services/migrations/gitea_downloader.go`)에 있는 버그입니다. 소스 Gitea/Forgejo 인스턴스 자체가 이전에 항목을 가져온 경우(예: GitHub에서), 해당 API는 poster를 `Ghost`로 반환하고 실제 로그인은 `original_author`/`original_author_id`에 담아 반환합니다. downloader는 `Poster.UserName`만 읽기 때문에 원래 작성자가 유실됩니다. 해결 방법: (1) 마이그레이션 후 데이터베이스를 직접 수정하여 소스 API의 `original_author` 필드로부터 작성자 이름을 복원합니다(보고자는 이 방법으로 약 9,100개의 issue/comment/review를 수정했습니다). (2) 영구적인 수정을 위해서는, poster가 Ghost 사용자이거나 `original_author`가 설정된 경우 `PosterName`/`PosterID`에 `original_author`/`original_author_id`를 사용하도록 downloader를 패치한 다음 마이그레이션을 다시 실행하십시오. Forgejo 15.x 및 유사한 소스에서 Gitea 28.0.0으로의 마이그레이션에 영향을 미칩니다.

Gitea 프로필에서 스타 표시된 저장소 수가 음수로 나타나는 문제를 어떻게 해결하나요?

이것은 일관성이 없거나 갱신되지 않은 사용자 star 카운터입니다. 근본적인 버그는 Gitea PR #26544에서 수정되었으므로, 해당 수정이 포함된 더 최신의 1.22 nightly 또는 이후 릴리스로 업그레이드하세요. try.gitea.io에서는 사용자가 사이트 관리자가 해당 수정을 배포할 때까지 기다려야 합니다. 자체 호스팅 인스턴스에서 업그레이드 후에도 여전히 음수 값이 표시된다면, 데이터베이스를 백업하고 실제 `star` 행을 기준으로 카운터를 다시 동기화하세요. MySQL: ```sql UPDATE `user` SET `num_stars` = ( SELECT COUNT(*) FROM `star` WHERE `star`.`uid` = `user`.`id` ); ``` PostgreSQL/SQLite: ```sql UPDATE "user" SET "num_stars" = ( SELECT COUNT(*) FROM "star" WHERE "star"."uid" = "user"."id" ); ``` 수정을 적용한 후 Gitea를 재시작하거나 프로필 페이지를 새로고침하세요.

gitea

Q: Gitea/Forgejo에서 Gitea로 마이그레이션한 후 이슈와 댓글의 작성자가 'Ghost'로 표시되는 이유는 무엇인가요?

이것은 Gitea의 migration downloader(`services/migrations/gitea_downloader.go`)에 있는 버그입니다. 소스 Gitea/Forgejo 인스턴스 자체가 이전에 항목을 가져온 경우(예: GitHub에서), 해당 API는 poster를 `Ghost`로 반환하고 실제 로그인은 `original_author`/`original_author_id`에 담아 반환합니다. downloader는 `Poster.UserName`만 읽기 때문에 원래 작성자가 유실됩니다. 해결 방법: (1) 마이그레이션 후 데이터베이스를 직접 수정하여 소스 API의 `original_author` 필드로부터 작성자 이름을 복원합니다(보고자는 이 방법으로 약 9,100개의 issue/comment/review를 수정했습니다). (2) 영구적인 수정을 위해서는, poster가 Ghost 사용자이거나 `original_author`가 설정된 경우 `PosterName`/`PosterID`에 `original_author`/`original_author_id`를 사용하도록 downloader를 패치한 다음 마이그레이션을 다시 실행하십시오. Forgejo 15.x 및 유사한 소스에서 Gitea 28.0.0으로의 마이그레이션에 영향을 미칩니다.

Q: Gitea 프로필에서 스타 표시된 저장소 수가 음수로 나타나는 문제를 어떻게 해결하나요?

이것은 일관성이 없거나 갱신되지 않은 사용자 star 카운터입니다. 근본적인 버그는 Gitea PR #26544에서 수정되었으므로, 해당 수정이 포함된 더 최신의 1.22 nightly 또는 이후 릴리스로 업그레이드하세요. try.gitea.io에서는 사용자가 사이트 관리자가 해당 수정을 배포할 때까지 기다려야 합니다. 자체 호스팅 인스턴스에서 업그레이드 후에도 여전히 음수 값이 표시된다면, 데이터베이스를 백업하고 실제 `star` 행을 기준으로 카운터를 다시 동기화하세요. MySQL: ```sql UPDATE `user` SET `num_stars` = ( SELECT COUNT(*) FROM `star` WHERE `star`.`uid` = `user`.`id` ); ``` PostgreSQL/SQLite: ```sql UPDATE "user" SET "num_stars" = ( SELECT COUNT(*) FROM "star" WHERE "star"."uid" = "user"."id" ); ``` 수정을 적용한 후 Gitea를 재시작하거나 프로필 페이지를 새로고침하세요.

SHA-256

55.6k stars·개발 도구·SHA-256 체크섬 확인됨

가볍고 크로스 플랫폼이며 자체 호스팅하기 쉬운 Git 서비스로, 활발한 커뮤니티와 풍부한 기능을 갖추고 있습니다.

스마트 다운로드

Download 버전 다운로드

v1.26.1 · 117.2 MB

Go로 작성된 자체 호스팅 Git 서비스로, GitLab보다 가볍고 Gogs보다 활발합니다.

주요 기능

경량 단일 바이너리 파일로 리소스 사용량이 매우 적음
내장 CI/CD(Gitea Actions), 패키지 관리, Wiki, 이슈 추적
다양한 인증 방식 지원(LDAP, OAuth, SMTP 등)
풍부한 Webhook 및 API 통합
GitHub/GitLab 리포지토리 마이그레이션 가능

할 수 없는 것

•프로덕션 환경에서는 MySQL/PostgreSQL과 리버스 프록시(Nginx/Caddy)를 구성하는 것이 좋으며, 기본 SQLite는 테스트에만 적합합니다. 처음 설치할 때 올바른 도메인과 기본 경로를 설정해야 하며, 그렇지 않으면 이후 마이그레이션이 번거로울 수 있습니다. 내장 Actions Runner는 별도로 설치해야 합니다.

사용 사례

개인 또는 소규모 팀의 프라이빗 코드 호스팅 플랫폼 구축
인트라넷 개발 환경, GitHub/GitLab 대체
저비용, 높은 제어성의 DevOps 인프라가 필요한 기업

Gitea는 커뮤니티가 유지 관리하는 셀프 호스팅 Git 서비스로, Go 언어로 작성되었습니다. 자체 Git 저장소를 구축하는 가장 간단하고 빠르며 번거롭지 않은 방법을 제공하는 것을 목표로 합니다. 2016년 Gogs에서 포크되었으며, 현재 커뮤니티가 매우 활발하고 기능도 크게 강화되었습니다. Go 언어가 지원하는 모든 플랫폼(Linux, macOS, Windows의 x86, amd64, ARM, PowerPC)을 지원합니다. 기능에는 저장소 관리, 이슈 트래킹, Pull Request, 코드 리뷰, 내장 CI/CD(Actions), 패키지 관리, Wiki 등이 포함됩니다. 단일 바이너리 파일로 직접 실행하거나 Docker를 통해 배포할 수 있습니다. 또한 호스팅 클라우드 서비스(Gitea Cloud)도 제공하여 빠르게 시작할 수 있습니다.

시작하기

설치 프로그램 다운로드

위 버튼을 클릭하여 시스템에 맞는 설치 프로그램을 다운로드

Windows· 117.2 MB Linux· 105.9 MB

소프트웨어 설치

다운로드한 설치 프로그램을 더블 클릭하고 안내에 따르세요

https://dl.gitea.com/gitea/latest/ 로 이동하여 해당 운영 체제의 최신 바이너리 파일을 다운로드하세요

바이너리 파일을 원하는 디렉터리에 넣고 `./gitea web`을 실행하여 서비스를 시작하세요(첫 실행 시 설치 마법사로 이동합니다)

브라우저를 열어 http://localhost:3000 에 접속한 후 마법사에 따라 데이터베이스와 관리자 계정을 설정하면 바로 사용할 수 있습니다

설치 가이드

https://dl.gitea.com/gitea/latest/ 로 이동하여 해당 운영 체제의 최신 바이너리 파일을 다운로드하세요
바이너리 파일을 원하는 디렉터리에 넣고 `./gitea web`을 실행하여 서비스를 시작하세요(첫 실행 시 설치 마법사로 이동합니다)
브라우저를 열어 http://localhost:3000 에 접속한 후 마법사에 따라 데이터베이스와 관리자 계정을 설정하면 바로 사용할 수 있습니다

파일 무결성

SHA-256 체크섬 확인됨

GitHub 공식 Release 페이지에서 추출된 체크섬

SHA256 체크섬

d0f88f56b795481ce438f3053bacf0d6ac153455e3fa8a626bbac9e79463c305

이 체크섬은 GitHub Release 페이지에서 추출되었습니다. 다운로드 후 파일 무결성을 확인하세요.

이 플랫폼의 모든 SHA-256 체크섬은 프로젝트의 공식 GitHub Release 페이지에서 추출되었으며, 어떠한 변경도 없습니다. GitHub Releases 페이지에서 직접 검증할 수 있습니다.

오픈소스 투명성

GitHub 소스 보기

환경 가이드

제거 정보

Gitea 바이너리 파일과 데이터 디렉토리(기본값 ~/.gitea 또는 사용자 정의 경로)를 삭제하면 완전히 제거됩니다

추가 의존성 없음

다운로드 후 바로 사용 가능. 추가 런타임이 필요하지 않습니다.

프로젝트 정보

라이선스MIT

마지막 업데이트2026-10-24 10:57:34

GitHub 저장소 공식 웹사이트

문제 발생? 아래 FAQ 확인

5 FAQs

유사한 프로젝트

lazygit

간단하고 사용하기 쉬운 터미널 기반 Git 그래픽 인터페이스로, Git 작업을 더 빠르고 직관적으로 수행할 수 있습니다.

Visual Studio Code (Code - OSS)

Microsoft가 만든 무료 오픈 소스 코드 편집기로, 지능형 자동 완성, 디버깅, Git 및 확장 기능을 지원하는 전 세계에서 가장 인기 있는 편집기입니다.

opencode

오픈소스 AI 코딩 에이전트로, 코드 작성, 리팩토링 및 분석을 지원하며, '빌드(Build)'와 '플랜(Plan)' 이중 에이전트 모드가 내장되어 있습니다.