Gitea とは？自分たちのサーバーで動かす Git 開発サービスの全体像

ソースコードを複数人で書いていると、「最新のファイルはどれか」「誰がいつ、どこを直したのか」という悩みが必ず出てきます。この悩みを解決する仕組みが Git で、Git で管理したコードを置き、メンバーで共有する場所が「Git ホスティングサービス」です。Gitea は、その場所を自分たちのサーバーに用意するためのソフトウェアです。

Gitea は、自分たちを「セルフホスト型で、すべてを一つにまとめた開発サービス」と説明しています。コードの保管だけでなく、変更内容のレビュー、課題の管理、自動テストの実行、成果物の配布までを、一つの画面とひとつのサービスで扱えます。この記事では、Gitea が何をするものなのか、何に向いていて、何を引き受ける必要があるのかを順に整理します。

自分で動かすということは、自分で守るということ

最初に、導入前に知っておきたい負担から書きます。Gitea はセルフホスト型です。サービスを動かすサーバーを用意し、起動し続け、更新し、壊れたときに戻せるようにするのは、利用する側の仕事になります。

具体的には、次の三つが日常の作業として発生します。

• バックアップを取る仕事です。 ソースコードは組織の財産であり、失われると取り戻せません。Gitea のバックアップは、サービスを止めたうえで専用のコマンドを実行する形が基本です。取り方と戻し方は、バックアップとリストアで詳しく扱います。
• 更新を続ける仕事です。 新しいバージョンが出たら、変更点を確認したうえで入れ替えます。マイナーバージョンをまたぐ更新ではデータベースの構造も書き換わるため、事前のバックアップが前提です。進め方はアップグレードの進め方にまとめています。
• 実行環境を信頼できるものに保つ仕事です。 Gitea Actions のようにジョブを別の実行役（ランナー）に任せる機能では、信頼できないランナーを使わないことが重要だと明記されています。サーバーの管理が一か所に集まる分、その一か所の安全に責任を持つことになります。

クラウド上の既成サービスを使えば、これらの作業は提供側が担ってくれます。Gitea を選ぶということは、その手間と引き換えに、データの置き場所・機能の使い方・費用の構造を自分たちで決める道を選ぶことです。そこで次に、その見返りが何なのかを見ていきます。

コードから配布まで、一つの画面で完結する

Gitea が扱う領域は、リポジトリの閲覧だけにとどまりません。ドキュメントでは、次のような機能が挙げられています。

この表の中身が一つのサービスにまとまっていることには、実務上の意味があります。たとえば、課題に書かれた不具合の報告から修正のブランチを作り、プルリクエストでレビューを受け、マージされたらワークフローが自動でテストとビルドを行い、できあがったコンテナイメージを同じサービスのレジストリに登録する、という流れが、サービスを行き来せずに完結します。ツールごとにアカウントや権限を作り直す必要がありません。

権限の考え方も一貫しています。リポジトリの各機能には「読む」「書く」といった水準が定められ、チーム単位でまとめて割り当てられます。メンバーの入れ替わりがあっても、チームの所属を変えるだけで済みます。この仕組みは、組織とチームで権限を設計するで具体例とともに取り上げます。

小さなサーバーでも動き出せる理由

Gitea は Go 言語で作られています。Go で書かれたプログラムは、実行に必要なものが一つのファイルにまとまりやすく、対応する環境が広いのが特徴です。Gitea のリポジトリには、Linux、macOS、FreeBSD や OpenBSD、Windows といった OS と、x86、amd64、ARM、RISC-V 64、PowerPC といった CPU に対応していると記載されています。

そのため、大きなサーバーを持たない組織でも導入しやすくなっています。Raspberry Pi のような ARM の小型機でも、事務所の片隅にある古い PC でも、同じソフトウェアが動きます。バイナリ（実行ファイル）で導入する場合に必要なのは、Git 2.0 以上と、使うデータベースの準備だけです。データベースは、何も設定しなければ SQLite が使われます。SQLite は別のサービスを立ち上げる必要がなく、試用や少人数での利用には手軽です。

導入の方法も選べます。バイナリを置いて起動する方法、Docker のイメージを使う方法があり、まず試すだけなら Docker が最短です。手順はDocker Compose で Gitea を導入するで、設定ファイルの全体を示します。

軽く動くことは、運用の負担を下げる効果もあります。必要なリソースが小さければ、専用のサーバーを新たに調達する理由が減り、既存の環境に同居させやすくなります。先に挙げた「自分で守る」負担を、無理のない範囲に収めるための土台になっているのです。

MIT ライセンスと、複数言語の画面

Gitea は MIT ライセンスのオープンソースです。MIT ライセンスは、利用・改変・再配布を広く認める、条件の少ないライセンスとして知られています。社内での利用に追加の費用は発生せず、ソースコードも公開されているため、どのような仕組みで動いているのかを自分たちで確認できます。

もうひとつ、利用者にとって大きいのが多言語対応です。Gitea は画面を複数の言語で表示できる作りになっており、メンバーが使い慣れた言語で操作できます。開発に慣れていない人が加わる場面でも、画面の言葉が母語であることは、最初のつまずきを減らします。

どんな組織に向いているか

ここまでの内容を踏まえると、Gitea が力を発揮するのは、次のような状況です。

最後の「SQLite のまま多くの利用者が使う」という点には注意が必要です。ドキュメントは、データベースの種類は最初の導入時に選ぶものであり、SQLite は規模が大きくなる場合に向かないと述べています。別の種類のデータベースへ変換する作業も、十分に検証された手順ではないと明記されています。使う人数が増えそうなら、最初から MySQL や PostgreSQL を選ぶのが安全です。選び方はデータベースの選び方で整理しています。

Gitea を構成する部品を知っておく

導入を考えるときは、Gitea が何と何で成り立っているのかを、先に頭に入れておくと見通しがよくなります。ドキュメントの説明をたどると、次の部品が見えてきます。

• Gitea 本体です。 Web の画面と、Git の通信を受け付けるプログラムです。HTTP の通信用のポートと、SSH の通信用のポートの二つを使います。Docker の例では、画面が 3000 番、SSH がコンテナ内の 22 番です。
• データベースです。 利用者、組織、課題、プルリクエストの情報など、リポジトリの中身以外のデータを保管します。
• リポジトリのディレクトリです。 Git のデータそのものが保存される場所です。バックアップの対象に、リポジトリのディレクトリが独立して含まれていることからも、データベースとは別に管理されていると分かります。
• データのディレクトリです。 添付ファイル、アバター、LFS のデータなどが入ります。設定の APP_DATA_PATH で場所が決まります。
• 設定ファイル app.ini です。 動作に関する設定をまとめたファイルです。環境変数で上書きすることもできます。
• ランナーです。 Gitea Actions のジョブを実行する、別のプログラムです。本体とは別のマシンに置くこともできます。
• 外部のストレージです。 設定すれば、S3 や MinIO のような外部のストレージにデータを置けます。更新のときのバックアップの対象に、外部のストレージも含まれることが、ドキュメントに書かれています。

部品が分かれていることは、運用の面で意味を持ちます。バックアップでは、データベース、リポジトリ、データ、設定のどれが欠けても、完全には戻せません。更新では、データベースの構造が書き換わります。ランナーは、本体と別に信頼を考えます。この記事のあとに並ぶ導入、バックアップ、更新、自動化の各記事は、どれもこの部品のどこを扱っているのかを意識すると、理解しやすくなります。

導入した組織の、ある一日を想像する

機能の一覧だけでは、実際の使い心地が思い浮かびにくいものです。ここでは、Gitea を使う小さな開発チームの一日を、想像上の例として描いてみます。実在の組織の話ではなく、機能の関係を理解するための例です。

朝、担当者が課題の一覧を開き、直す予定の不具合を一つ選びます。課題には、不具合の内容と、再現する手順が書かれています。担当者は、その課題をもとに作業用のブランチを作り、修正をコミットして push します。

昼前に、プルリクエストを出します。タイトルの先頭には WIP: を付け、途中経過であることを示します。チームの仲間が画面を開き、変更の方向性についてコメントを残します。担当者はコメントを受けて追加のコミットを送り、仕上がった段階で、WIP: を外します。

プルリクエストが出された時点で、ワークフローが自動で動き、テストが実行されます。結果は、プルリクエストの画面で確認できます。担当の仲間は、テストが通っていることを見たうえで、差分を読み、承認します。マージされたあとは、ビルドの成果物が、パッケージとして登録されます。

この一日の中で、利用者は画面を行き来していません。課題、ブランチ、プルリクエスト、自動テスト、成果物の登録が、同じサービスの上でつながっています。ひとつの流れの中で、誰が、いつ、何をしたのかが記録として残り、あとから振り返れることも、運営する側にとっては大きな利点です。

もちろん、これは理想的な流れの一例です。実際には、チームの規模や、扱うものの性質によって、必要な機能は変わります。すべてを一度に使いこなそうとせず、まずはリポジトリとプルリクエストから始め、必要に応じて自動化や成果物の管理を足していく進め方が、無理がありません。

手元で動かして確かめるところから

Gitea を知るいちばん確かな方法は、実際に動かしてみることです。Docker が使える環境なら、設定ファイルを一つ書いて起動するだけで、数分でブラウザーから初期設定の画面を開けます。テスト用のリポジトリを一つ作り、ファイルを push して、プルリクエストを作る。そこまで体験すれば、普段使っているサービスとの違いや、自分たちの運用に合うかどうかが具体的に見えてきます。

自分で運用する負担は確かにあります。一方で、データの置き場所を自分で決められること、機能が一つのサービスにそろっていること、小さな環境でも動くことは、多くの組織にとって大きな利点です。まずは試用の環境を作り、次の記事で導入の手順を確認してみてください。この記事の内容は、2026年11月15日時点のドキュメントに基づいています。