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 でもpanicに対する防御が追加されています。アップグレードできるまでの回避策: 1) 'Gitea' プロバイダーの代わりに汎用の 'Git' 移行プロバイダーを使用してください。これは正常に完了します(ただし、Gitデータのみがコピーされ、issue/PR/メタデータはコピーされない点に注意してください)。'certificate signer not trusted' というエラーが発生した場合は、まずソースサーバーのCAを移行先の信頼された証明書ストアにインストールしてください。2) できれば、移行は一切行わない方が望ましいです: Giteaのデータディレクトリとデータベース全体を旧サーバーから新サーバーにコピーし、新しいインスタンスを起動してインプレースアップグレードを行ってください。移行ではいずれにせよデータの100%がコピーされるわけではないためです。

v28.1.0で`git reflog expire --all`が原因で発生する60〜90秒のGiteaプッシュの停滞を修正するには、どうすればよいですか?

PR #39703 またはそのバックポートを含む Gitea リリースにアップグレードしてください。このリリースでは reflog の有効期限が Git のデフォルトに委ねられます。アップグレード後、既存のリポジトリから古い設定キーを削除してください。影響を受けるベアリポジトリに対する即時の回避策: ```bash # どの設定スコープに値が含まれているかを表示 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 days ago」(90 日前)ではなく 1990 年の日付として解析されるため、到達可能な reflog エントリは期限切れになりません。Git 2.54 以降では、プッシュによってトリガーされる自動メンテナンスが `git reflog expire --all` をフォアグラウンドで実行します。`core.logAllRefUpdates=true` を使用している負荷の高いベアリポジトリでは、数万件の `refs/pull/*` reflog のスキャンが `git-receive-pack` をブロックし、プッシュ後の遅延を引き起こします。

なぜGiteaはcron.git_gc_reposのTIMEOUTを無視して、git gcを長時間実行させるのか？

これは Gitea 1.27.3 および影響を受けた main ビルドのバグです。GitGcRepo は設定されたタイムアウトを受け取りますが、それを Git コマンドに渡さないため、context.DeadlineExceeded は決して適用されません。修正: 1. GitGcRepo のタイムアウト処理の修正を含む Gitea リリースにアップグレードします。 2. 修正済みリリースが利用できない場合は、services/repository/check.go にパッチを適用し、既存の fsck 実装と同様に、git gc コマンドチェーンに .WithTimeout(timeout) を追加します： err := git.NewCommand(ctx, "gc"). WithTimeout(timeout). // <-- これを追加 Run(&git.RunOpts{ Dir: repo.Path, }) 正確な呼び出しチェーンには SetDescription やその他のオプションが含まれる場合があります。Run の前に .WithTimeout(timeout) を追加してください。 3. Gitea を再ビルドして再デプロイし、その後、既存の設定を維持します： [cron.git_gc_repos] TIMEOUT = 8h 未パッチバージョンでの一時的な回避策：自動 GC ジョブを無効にし、Git ユーザーとして OS の timeout コマンドを使って手動で GC を実行します： [cron.git_gc_repos] ENABLED = false sudo -u git timeout 8h git -C /var/lib/gitea/git/repositories/owner/repo.git gc 以前の失敗した GC が古い gc.pid ロックを残した場合は、ロックファイルを削除する前に、そのリポジ

Gitea/Forgejo から Gitea に移行した後、Issue やコメントの作者が 'Ghost' と表示されるのはなぜですか?

これは Gitea のマイグレーションダウンローダー(`services/migrations/gitea_downloader.go`)のバグです。移行元の Gitea/Forgejo インスタンス自体が(GitHub などから)アイテムをインポートしていた場合、その API は投稿者を `Ghost` として返し、実際のログイン名は `original_author`/`original_author_id` に含まれます。ダウンローダーは `Poster.UserName` しか読み取らないため、元の作者情報が失われます。回避策: (1) マイグレーション後にデータベースを直接修正し、移行元 API の `original_author` フィールドから作者名を復元します(報告者はこの方法で約 9,100 件のイシュー/コメント/レビューを修正しました)。(2) 恒久的な修正としては、投稿者が Ghost ユーザーである場合や `original_author` が設定されている場合に、`PosterName`/`PosterID` として `original_author`/`original_author_id` を使用するようダウンローダーにパッチを適用し、その後マイグレーションを再実行します。Forgejo 15.x および同様のソースから Gitea 28.0.0 へのマイグレーションに影響します。

Giteaプロフィールでスター済みリポジトリ数が負の値になっている場合、どうすれば修正できますか？

これは、不整合/古くなったユーザースターカウンターです。根本的なバグは 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 に移行した後、Issue やコメントの作者が 'Ghost' と表示されるのはなぜですか?

これは Gitea のマイグレーションダウンローダー(`services/migrations/gitea_downloader.go`)のバグです。移行元の Gitea/Forgejo インスタンス自体が(GitHub などから)アイテムをインポートしていた場合、その API は投稿者を `Ghost` として返し、実際のログイン名は `original_author`/`original_author_id` に含まれます。ダウンローダーは `Poster.UserName` しか読み取らないため、元の作者情報が失われます。回避策: (1) マイグレーション後にデータベースを直接修正し、移行元 API の `original_author` フィールドから作者名を復元します(報告者はこの方法で約 9,100 件のイシュー/コメント/レビューを修正しました)。(2) 恒久的な修正としては、投稿者が Ghost ユーザーである場合や `original_author` が設定されている場合に、`PosterName`/`PosterID` として `original_author`/`original_author_id` を使用するようダウンローダーにパッチを適用し、その後マイグレーションを再実行します。Forgejo 15.x および同様のソースから Gitea 28.0.0 へのマイグレーションに影響します。

Q: Giteaプロフィールでスター済みリポジトリ数が負の値になっている場合、どうすれば修正できますか？

これは、不整合/古くなったユーザースターカウンターです。根本的なバグは 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）をサポートしています。機能には、リポジトリ管理、Issue トラッキング、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コーディングエージェント、コードの作成、リファクタリング、分析をサポートし、「ビルド」と「計画」のデュアルエージェントモードを内蔵。

gitea

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト