Forgejo — собственная платформа для Git-репозиториев и командной разработки

Forgejo позволяет хранить Git-репозитории, обсуждать изменения, вести задачи и запускать автоматические проверки на сервере, которым управляет сама команда. Это свободная платформа для небольших проектов, компаний и сообществ, которым нужен единый веб-интерфейс для работы с кодом и собственные правила доступа к нему.

Forgejo собирает код, задачи и обсуждения в одном веб-интерфейсе

Представим команду, которая разрабатывает интернет-магазин. Программисты хранят исходный код в Git, дизайнер прикладывает макеты к задачам, тестировщик сообщает об ошибках, а руководитель следит за подготовкой очередного выпуска. Forgejo объединяет эти действия вокруг проекта: участники видят историю изменений, обсуждают предложения и получают информацию о готовности новой версии.

Основа платформы — Git, система контроля версий. Она запоминает изменения в файлах и помогает нескольким людям работать с одним проектом. Репозиторий представляет собой хранилище с файлами и историей их изменений. Forgejo добавляет к нему страницы в браузере, управление доступом и инструменты совместной работы.

Разработчик продолжает пользоваться привычными командами git clone, git commit, git push и git pull. Через браузер он может просмотреть файлы, найти нужный коммит, изучить различия между версиями и обсудить правки. Для участников без опыта работы в терминале доступен веб-интерфейс с задачами, документацией и комментариями.

Forgejo распространяется как свободное программное обеспечение. Экземпляр платформы можно развернуть в собственной инфраструктуре, например на виртуальном сервере, внутри корпоративной сети или в домашней лаборатории. Администратор определяет, кто получает доступ к сервису и где хранятся его данные.

От Gitea до самостоятельного проекта под управлением сообщества

Forgejo появился в декабре 2022 года как ответ части сообщества на изменения в управлении проектом Gitea. Первоначально разработчики опирались на общий код двух систем. В 2024 году Forgejo перешёл к самостоятельному развитию: проекты постепенно расходятся по архитектуре, функциям и техническим решениям.

Доменные имена Forgejo находятся под опекой Codeberg e.V., зарегистрированной в Германии некоммерческой организации. Вопросы разработки и управления обсуждаются участниками сообщества. Такой способ организации важен для пользователей, которые оценивают долгосрочную доступность исходного кода и возможность самостоятельно поддерживать установку.

Начиная с Forgejo 9.0 проект использует лицензию GNU GPL версии 3 или более поздней. Она разрешает использование, изучение и изменение программы; при распространении производных версий действуют условия этой лицензии. Самостоятельная эксплуатация сервиса, включая коммерческие сценарии, допускается.

Название происходит от эсперантского слова forĝejo — «кузница». Разработчики называют подобные платформы software forge: место, где программный продукт проходит путь от исходных файлов и обсуждения задач до готового релиза.

Репозитории, запросы на изменения и доски задач организуют работу команды

Код и история изменений доступны через браузер

У каждого репозитория есть собственная страница. На ней можно просматривать ветки, коммиты, теги и опубликованные релизы. Ветки позволяют параллельно разрабатывать несколько функций. Теги обычно обозначают конкретные версии продукта, например v1.2.0.

Forgejo поддерживает доступ к репозиториям по HTTPS и SSH. Права настраиваются для пользователей и команд, а для важных веток предусмотрены ограничения на изменение. Это пригодится, когда выпускная ветка должна получать код только после проверки коллегами.

Задачи и запросы на слияние сохраняют контекст решений

В разделе Issues команда регистрирует ошибки, предложения и текущие работы. У задачи есть обсуждение, метки и другие средства организации. Например, сообщение «После оплаты пользователь остаётся на странице заказа» можно связать с изменением кода, которое исправляет поведение сайта.

Pull request — предложение включить изменения из одной ветки в другую. Коллеги изучают различия между версиями файлов, оставляют замечания и обсуждают результат. После согласования изменения объединяются. Такой процесс помогает сохранить историю решений и понять, почему конкретный фрагмент программы появился в проекте.

Для планирования доступны доски проектов, а для документации — встроенная Wiki. Поэтому в Forgejo можно держать рядом исходный код, список известных ошибок, инструкции по развёртыванию и описание новых возможностей.

Реестр пакетов хранит готовые компоненты

Встроенный Package Registry принимает пакеты, подготовленные для разных экосистем. В документации перечислены npm, Composer, PyPI, Maven, Cargo, NuGet и OCI-совместимые контейнерные образы.

Например, компания, разрабатывающая несколько PHP-приложений, может публиковать собственную библиотеку в реестре Composer и подключать её к другим проектам. Команда JavaScript-разработчиков получает аналогичный сценарий с npm. Для контейнеризированных приложений доступно хранение образов, которые затем загружает Docker или другой OCI-совместимый инструмент.

Здесь есть техническая тонкость: пакеты привязаны к пользователю или организации, а связь с конкретным репозиторием настраивается отдельно. Права доступа к пакетам тоже зависят от их владельца и параметров экземпляра.

Forgejo Actions запускает тесты и сборки после изменений в коде

Когда разработчик отправляет новую версию программы, её часто требуется проверить автоматически: запустить тесты, найти ошибки форматирования, собрать приложение или подготовить пакет. Для таких операций в Forgejo предусмотрена система Forgejo Actions.

Сценарии автоматизации описываются в YAML-файлах, которые обычно находятся в каталоге .forgejo/workflows внутри репозитория. В них указывается событие запуска и последовательность задач. Например, после отправки изменений в ветку система может выполнить PHP-тесты или собрать frontend на Node.js.

Непосредственное выполнение задач поручается отдельной программе Forgejo Runner. Её устанавливают и регистрируют отдельно. Разделение позволяет выделить для сборок специальный сервер, а также управлять тем, какие репозитории вправе передавать ему задания.

Часть синтаксиса напоминает GitHub Actions, поэтому знакомые сценарии будет легче читать. Полная совместимость между системами не гарантируется: официальная документация Forgejo отдельно описывает различия в поведении и поддерживаемых возможностях. Готовые workflow перед переносом проверяют с учётом используемых действий, контейнеров и секретов.

Автоматизация имеет и отдельные риски. Задание Runner выполняет команды, полученные из репозитория. Если злоумышленник добьётся запуска своего workflow в доверенном окружении, он может попытаться прочитать секреты, обратиться к внутренним сервисам или повлиять на файловую систему. Степень риска зависит от прав Runner, способа изоляции и того, какие участники имеют право изменять сценарии сборки.

Для установки достаточно сервера, базы данных и доступа к Git

Forgejo можно установить как исполняемый файл или запустить в контейнере Docker. Контейнерный вариант удобен там, где уже используются Docker Compose и постоянные тома для данных. Установка из бинарного файла подходит для сервера Linux с управлением службой через systemd.

Платформа хранит данные двух типов. Исходный код и другие файлы размещаются в файловом хранилище, а сведения о пользователях, задачах и обсуждениях записываются в базу данных. Согласно документации Forgejo 17.0 поддерживаются SQLite, PostgreSQL 14+, MariaDB 10.6+ и MySQL 8.4+. SQLite позволяет начать с небольшого экземпляра без отдельного сервера базы данных.

После запуска администратор открывает страницу первоначальной настройки, задаёт адрес сервиса, выбирает базу данных и создаёт учётную запись. Доступ по SSH можно организовать через встроенную службу или существующую инфраструктуру, в зависимости от схемы установки.

Для публичного сайта обычно используют домен и HTTPS. Перед Forgejo может работать Nginx, Apache, Caddy либо другой обратный прокси-сервер. В корпоративной сети экземпляр иногда доступен только через VPN. Параметры регистрации, авторизации, почты и внешнего адреса задаются отдельно.

Небольшая команда может начинать с компактной конфигурации. Потребление памяти и процессорного времени затем зависит от количества активных пользователей, объёма репозиториев, поискового индексирования и фоновых операций. Особенно заметную нагрузку создают сборки, поэтому Runner часто размещают отдельно от основного сервиса.

Собственный сервер даёт контроль над доступом и ответственность за сохранность данных

Самостоятельное размещение помогает организации определить физическое расположение хранилища, правила регистрации пользователей, доступность сервиса из интернета и порядок обновлений. Закрытые репозитории могут оставаться в частной сети без публикации на общедоступном хостинге.

За это отвечает администрирование. Если заканчивается место на диске, истекает TLS-сертификат или выходит критическое исправление, поддерживать работоспособность экземпляра приходится владельцу инфраструктуры или его подрядчику.

Резервная копия Forgejo включает больше компонентов, чем архив каталога с Git-репозиториями. Для полноценного восстановления требуются база данных, файловое хранилище, конфигурация app.ini и связанные с установкой секретные ключи. В частности, потеря значения SECRET_KEY может нарушить доступ к зашифрованным настройкам, включая учётные данные интеграций и секреты Actions.

Официальное руководство по резервному копированию предупреждает о риске несогласованного состояния данных при копировании работающей системы и рекомендует останавливать Forgejo на время резервирования. Если используются внешняя база данных, объектное хранилище или Redis, соответствующие данные также входят в схему восстановления.

Проверка доступа к Actions дополняет обычную защиту учётных записей. Для публичных репозиториев отдельное внимание требуется к workflow из pull request, сетевым разрешениям Runner и запуску контейнеров с повышенными привилегиями.

Перенос репозиториев и зеркалирование помогают сменить площадку

В Forgejo предусмотрены инструменты миграции проектов с других Git-платформ. При переносе обычного Git-репозитория сохраняется история коммитов, веток и тегов. Перенос задач, комментариев, запросов на слияние и других связанных данных зависит от исходной системы, её API и поддерживаемого способа миграции.

Отдельная возможность — зеркалирование репозитория. В этом режиме Forgejo периодически получает изменения из другого Git-хранилища либо отправляет их на внешнюю площадку. Зеркало удобно для публикации копии исходного кода или сохранения истории проекта на нескольких серверах. Обсуждения, права пользователей и настройки CI остаются отдельными частями рабочего процесса.

С переходом между Gitea и Forgejo связаны дополнительные вопросы совместимости конкретных версий: платформы развиваются самостоятельно с 2024 года. Поэтому миграция действующей инсталляции требует изучения соответствующего руководства по обновлению, а не только замены имени контейнера.

В выпуске Forgejo 17.0 появилась миграция из Bitbucket Data Center с поддержкой переноса запросов на изменение, обсуждений и рецензий при соблюдении описанных разработчиками условий. Это расширило набор сценариев перехода для команд, которые использовали локальные корпоративные Git-серверы.

Forgejo, GitHub, GitLab и Gitea различаются способом эксплуатации и развития

Все четыре платформы работают с Git-репозиториями и процессом коллективной разработки. Выбор зависит от того, где размещаются данные, какие интеграции нужны команде и кто отвечает за обслуживание.

Платформа	Размещение	Особенности для команды
Forgejo	Собственный сервер или сторонний экземпляр	Свободный код, управление сообществом, встроенные задачи, pull requests, Actions и реестр пакетов
GitHub	Прежде всего облачная служба GitHub	Большая публичная экосистема проектов и интеграций; правила обслуживания определяет провайдер
GitLab	Облачная служба и самостоятельная установка	Широкий набор средств для разработки и автоматизации; состав функций зависит от редакции и тарифа
Gitea	Собственный сервер и предлагаемые провайдером сервисы	Родственная Forgejo платформа со своей моделью развития и отдельными выпусками

Сходство интерфейсов Forgejo и Gitea объясняется общей историей. Со временем список функций и условия совместимости меняются. Для GitHub и GitLab существенную роль играет накопленная экосистема интеграций, а для Forgejo — самостоятельное размещение, свободная лицензия и управление сообществом.

У самохостинга есть организационная цена: кто-то должен выполнять обновления, следить за диском, проверять резервные копии и реагировать на инциденты. У облачного провайдера значительная часть инфраструктурных операций входит в услугу, но условия доступа и хранения данных зависят от выбранного сервиса.

Forgejo 17.0 расширил автоматизацию и управление проектами

15 октября 2026 года вышел Forgejo 17.0. Среди изменений — автоматические подсказки номеров задач и pull requests в комментариях, улучшенное управление файлами Git LFS, приглашения пользователей в организации и более подробные события для вебхуков.

Для Forgejo Actions появились дополнительные возможности API и отображение кратких отчётов заданий в формате Markdown. Такие отчёты могут содержать таблицы, диаграммы Mermaid и математические формулы. Добавлена поддержка файла FUNDING.yml, с помощью которого проект показывает варианты финансовой поддержки в интерфейсе.

Выпуск содержит изменения, влияющие на совместимость: в документах внутри репозиториев иначе обрабатываются абсолютные ссылки, а старый тип событий вебхука action run объявлен устаревающим. Это относится к действующим установкам, использующим соответствующие ссылки или интеграции.

Версия 17.0 — обычный выпуск с поддержкой до 28 января 2027 года. Для инфраструктуры с длительным циклом обновлений существует ветка 15.0 LTS, поддержка которой запланирована до 15 июля 2027 года. Эти сроки опубликованы в официальном анонсе Forgejo 17.0.

Forgejo остаётся инструментом для самостоятельного управления разработкой

Forgejo охватывает повседневный цикл программного проекта: репозитории Git, обсуждение изменений, задачи, документацию, выпуск версий и автоматические проверки. Он работает на инфраструктуре, выбранной владельцем установки, и развивается как независимый проект свободного программного обеспечения.

Масштаб внедрения определяет характер эксплуатации. Для личных проектов достаточно сравнительно простой установки, а работа команды с постоянными сборками, внешними интеграциями и закрытыми репозиториями добавляет задачи по управлению доступом, изоляции автоматизации и восстановлению данных. Дальнейшее развитие Forgejo будет зависеть от решений сообщества и того, какие возможности войдут в последующие релизы.