Со временем я стал задаваться вопросом — можем ли мы в своей стране своими силами создать аналогичную экосистему? В которой нет проблем с платежами, не удаляют репозитории и аккаунты из-за поездки в Крым, где российские компании заказчики не опасаются хостить свои коммерческие проекты. В 2023 году я попробовал GitFlic, но не смог им пользоваться из-за нестабильной работы репозиториев. В 2025 году я решил попробовать GitVerse. Проекту уже больше года, и, скорее всего, он созрел для реального применения. В первую очередь меня интересует, есть ли у GitVerse потенциал стать не просто надёжным хостингом для GIT-репозиториев, а развиться в мощную экосистему, не просто повторить функционал GitHub в масштабе 1:43, а реализовать новое поколение индустриальных стандартов для совместного творчества разработчиков и других IT-специалистов.

Первый признак живой экосистемы — расширение возможностей платформы силами её пользователей. Чтобы проверить это, я попробую создать расширение для встроенной в GitVerse IDE, максимально используя инструменты платформы. Чем больше практических задач по разработке и распространению расширения я смогу решить, не выходя за рамки GitVerse, тем он ближе к превращению в самостоятельную экосистему.

Проектируем расширение для GitVerse

GitVerse предоставляет две IDE с поддержкой плагинов и расширений: GigaIDE Desktop на базе IntelliJ IDEA и GigaIDE Cloud на базе VS Code. У меня больше опыта в работе с VS Code и JavaScript, поэтому я буду делать расширение для GigaIDE Cloud. Это позволит не тратить время на изучение незнакомого окружения.

Функциональное назначение расширения, которое я собираюсь реализовать, заключается в графовом отображении структуры открытого в IDE проекта. Это полезно для быстрого визуального анализа и определения зависимостей между компонентами. Весь код проекта, со всеми файлами и их содержимым, должен будет рендериться в виде графа целиком на одной странице, с возможностью плавной навигации через pan/zoom к интересующим пользователя местам. В интерфейсе расширения пользователь сможет задавать зависимости, которые хочет увидеть в виде направленных связей между узлами графа.

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

Создаём репозиторий для расширения

Создать репозиторий в GitVerse легко, процесс не отличается от GitHub, функциональных ограничений или ошибок в процессе создания обнаружено не было. Сначала я создал организацию для всех репозиториев своего проекта, и в ней создал репозиторий конкретно для расширения под GigaIDE Cloud. В перспективе это позволит удобно организовывать работу команды над проектом.

Для разработки я решил сразу начать использовать встроенные инструменты — GigaIDE Cloud и GigaCode. Запустить облачный инстанс IDE для репозитория просто, бесплатного машинного времени в облаке предоставляется достаточно много, чтобы полноценно работать над одним проектом. Главное — не забывать ставить инстанс на паузу, когда он не используется. Еcли нужно работать сразу над несколькими проектами, тогда придётся переходить на платный тариф. GigaCode работает бесплатно как в Desktop, так и в Cloud версиях IDE.

Первая задача, которую я собираюсь выполнить в IDE, — создать и запустить расширение-пустышку в стиле Hello World. До этого я никогда не создавал расширений для VS Code-совместимых IDE, поэтому для быстрого старта вместо чтения документации я хочу поручить эту задачу ИИ-ассистенту. К сожалению, GigaIDE пока не имеет Agent Mode для GigaCode, поэтому не может писать код напрямую в файлы проекта, как это делает, например, Cursor или Windsurf. На вопрос о том, как создать расширение, GigaCode посоветовал мне использовать генератор кода Yeoman. Я попробовал — и мне не понравилось. Это слишком перегруженное деталями решение, и не подходит для быстрого минималистичного старта. В итоге я сам нашёл в GitHub удобный проект для начала работы над расширением. Что особенно понравилось — это возможность запустить отладку напрямую из IDE через меню Run & Debug. При этом в одном инстансе идёт отладка бэкенда, а во втором — отладка фронтенда в webview.

Дальше я хочу убедиться, что расширение работает в других IDE. Но не хочу для этого публиковать его в маркетплейсы. GigaCode порекомендовал следующее:

1. Установить пакет vsce и собрать vsix-пакет
   npm install -g vsce
vsce package

2. Установить vsix-пакет в целевую IDE
   Cmd+Shift+P, Extensions: Install from VSIX...

3. Запустить команду расширения, чтобы убедиться, что оно корректно работает
   Cmd+Shift+P, Example: Hello World

Рекомендация оказалась полезной — я убедился, что моё расширение работает в VS Code, VSCodium, Cursor и Windsurf.

По итогу проделанной работы мне понравился интерфейс и логика функционирования GitVerse, видно, что над UI/UX была проведена серьёзная работа. Основные востребованные функции выглядят понятно, доступно, работают стабильно. Думаю, для любого, кто имеет опыт работы с GitHub, будет несложно стартовать разработку в GitVerse.

Также заметно, что по объективным причинам GitHub имеет больше разнообразных функций, чем GitVerse. Мне хотелось бы иметь в GitVerse две дополнительные возможности, которые есть в GitHub:

1. Отдельный контактный email для личных профилей и организаций. Сейчас в GitVerse можно сделать публичным свой управляющий email, но это небезопасно с точки зрения защиты от спама. Для публичных контактов должна быть возможность указывать отдельный контактный email, не совпадающим с управляющим email’ом.

2. Тёмная тема. Все мои рабочие инструменты настроены на тёмные темы, и только GitVerse сияет ярким белым фоном.

Публикуем расширение в маркетплейсах

Я решил сначала опубликовать расширение-пустышку в режиме preview, а потом начать разработку полезного функционала, чтобы на самой ранней стадии понять все особенности процесса публикации, и учесть их при дальнейшем планировании разработки. По итогам беглого изучения вопроса маркетплейсов для VS Code-совместимых IDE выяснилось, что доступно всего два решения: индустриальный лидер Visual Studio Marketplace от Microsoft и более скромная, менее стабильная, но более открытая альтернатива — Open VSX Registry от Eclipse Foundaton. GigaIDE Cloud по умолчанию использует Open VSX, но при необходимости можно попробовать перенастроить его на маркетплейс от Microsoft. Независимых отечественных маркетплейсов для расширений я не обнаружил.

Также есть возможность публиковать расширение не в маркетплейсе, а в виде обычного бинарного релиза прямо в GitVerse. Может быть, это не так удобно с точки зрения пользователей, зато более надёжно с точки зрения доступности и обеспечивает простой процесс публикации для разработчика.

GitVerse Releases

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

Open VSX Registry

Вопреки моим ожиданиям процесс регистрации на open-vsx.org оказался довольно сложным и запутанным. Перед началом нужно знать несколько неочевидных моментов, которые мне пришлось выяснять по ходу дела.

1. Компания Eclipse Foundation на данный момент не препятствует работе пользователей с российскими IP-адресами и проживающих в России, поэтому можно регистрироваться без VPN, указывать свой настоящий почтовый адрес и использовать email в зоне RU без опасений подвергнуться блокировке.

2. Для публикации расширений необходимы связные аккаунты на github.com и eclipse.org, а также созданный на open-vsx.org namespace.

3. Namespace на Open VSX является аналогом издателя на Visual Studio Marketplace, к нему прикрепляются все ваши релизы расширений. Чтобы получить возможность управлять своим namespace’ом, необходимо подтвердить права на него через создание issue в GitHub репозитории Eclipse Foundation.

Пошаговая инструкция по публикации расширения на Open VSX:

1. Создать аккаунт на github.com, если его ещё нет, или выбрать наиболее подходящий аккаунт из уже существующих. В будущем этот аккаунт будет невозможно заменить на другой, учитывайте это при выборе.

2. Создать аккаунт на eclipse.org и связать его с GitHub-аккаунтом, выбранным на шаге 1.

3. Авторизоваться на eclipse.org со своего аккаунта и подписать соглашение контрибьютора — Eclipse Contributor Agreement (ECA). В процессе подписания соглашения придётся указать свой почтовый адрес. После подписания уже не получится сменить GitHub-аккаунт, привязанный к Eclipse-аккаунту. В вашем профиле будет написано, что сменить его можно, если написать письмо в support. Но на практике такие письма остаются без ответа.

4. Авторизоваться на open-vsx.org под GitHub-аккаунтом, выбранным на шаге 1.

5. Авторизоваться внутри профиля на open-vsx.org через свой Eclipse-аккаунт. По сути, это двухступенчатая авторизация. В результате подписанный вами ECA подтянется с eclipse.org на open-vsx.org, и потребуется подписать ещё одно соглашение, относящееся непосредственно к Open VSX.

6. Создать на open-vsx.org уникальный namespace, под которым в дальнейшем будет осуществляться публикация расширений. У меня это "knyte", у вас будет что-то другое. Такое же название желательно использовать и в Visual Studio Marketplace как название своего издателя. Это обеспечит единообразие именований на всех платформах.

7. Прописать namespace в package.json расширения в качестве атрибута издателя:
   {
"publisher": "knyte"
}

8. Собрать vsix-пакет локально и загрузить его на open-vsx.org в разделе Extensions -> Publish.
   vsce package

9. Подтвердить свои права на namespace. Несмотря на то что namespace уже создан в профиле, и на него опубликовано расширение, права на namespace не закреплены за пользователем, и полноценное управление недоступно. Чтобы это исправить, нужно запросить права на namespace, создав соответствующий issue по ссылке с темой "Claiming namespace". Правила оформления issue и примеры запросов от других пользователей доступны в репозитории по той же ссылке.

10. Убедиться, что права на namespace выданы. Обычно на это уходит 1–2 рабочих дня. После выдачи прав, в профиле на open-vsx.org, в разделе Namespaces появятся инструменты управления namespace’ом. В маркетплейсе на странице расширения появится значок верифицированного издателя.

Visual Studio Marketplace

На этой платформе процесс регистрации построен более логично, и пройти его проще. Официальная инструкция доступна здесь. Компания Microsoft также не препятствует пользователям из России в работе с маркетплейсом.

Пошаговая инструкция по публикации расширения на Visual Studio Marketplace:

1. Пройти регистрацию на Azure DevOps или использовать уже имеющийся аккаунт Microsoft, GitHub или Skype для входа.

2. Создать организацию здесь и сгенерировать для неё Personal Access Token, который в дальнейшем будет использоваться для авторизации CLI-инструментов маркетплейса.

3. Создать издателя для маркетплейса здесь.

4. Опубликовать расширение через терминал в IDE, используя vsce.
   vsce login knyte
vsce publish
Если vsce не обнаружит никаких ошибок при сборке и публикации расширения, в личном кабинете издателя появится задача на верификацию расширения. После проведения автоматической проверки на вредоносный код, которая обычно занимает 5 минут, расширение станет доступно в маркетплейсе.

5. Верифицировать сайт издателя. Иначе у вашего расширения в маркетплейсе не будет значка верификации, и каждый раз при попытке установки расширения пользователи будут видеть предупреждающие сообщения. Верификация состоит из двух частей: технической и организационной. Для прохождения технической части достаточно иметь сайт организации на собственном домене. Следуя инструкциям из личного кабинета издателя, нужно прописать в настройках DNS домена определённое TXT поле и отправить запрос на ручную проверку своего сайта. В течение 3–5 рабочих дней сотрудник Microsoft проведёт проверку и напишет вам письмо с результатами. Для прохождения организационной части верификации необходимо, чтобы с момента публикации расширения прошло не менее 6 месяцев, он имел существенное количество загрузок и хорошую репутацию среди пользователей. После этого можно заново подать запрос на верификацию и получить полноценный статус проверенного издателя.

Развиваем функционал расширения

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

1. Визуализация файловой структуры проекта в виде графа на базе SVG рендера.

2. Исключение из списка для отрисовки лишних файлов, не несущих смысловой нагрузки для проекта.

3. Текстовый и символьный поиск по проекту с отображением результатов в графе.

Тестирование расширения я планирую проводить на репозиториях популярных Open source проектов различного размера:

• uuidv7-js

• hge

• box2d

• three.js

• godot

• node

• linux

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

Выбираем инструменты для разработки и тестирования

Изначально я хотел вести разработку и тестирование исключительно с помощью встроенных инструментов GitVerse, но довольно быстро натолкнулся на ряд существенных ограничений, которые заставили меня дополнительно использовать GitHub и Cursor.

Первым очевидным ограничением стало отсутствие Agent Mode в GigaIDE Cloud и Desktop. Если в Cursor я могу передать ИИ-ассистенту контекст из файлов, составить промпт и получить результат сразу в файлах проекта, то с GigaIDE приходится тратить время на рутинное копирование и вставку сгенерированного кода из чата в файлы.

Следующим ограничением стал уровень ответов GigaCode по сравнению с Claude 3.7 Sonnet, который доступен в Cursor. На простых запросах GigaCode справляется неплохо, но на более сложных практических задачах начинает вводить в заблуждение. Например, мне понадобилось реализовать в расширении на webview функционал, аналогичный prompt на обычной веб-странице. GigaCode предложил использовать стандартную команду prompt в контексте webview, и это не является рабочим решением, потому что VS Code запрещает расширениям вызывать всплывающие окна из webview по соображениям безопасности. На тот же запрос Claude выдал решение, в котором фронтенд расширения из события на webview отправляет сообщение на бэкенд расширения, бэкенд запускает встроенный диалог из IDE, получает результат диалога и отправляет его на фронтенд с помощью другого сообщения. На первый взгляд это решение кажется переусложнённым, но на самом деле оно учитывает все особенности работы расширений с диалогами, и мне удалось его запустить после минимальных правок сгенерированного кода.

Необходимо отметить, что Claude тоже имеет ограниченные возможности. Например, если попросить его переписать довольно медленный SVG-рендеринг на оптимизированный низкоуровневый WebGL-рендеринг, то он не справится с этой задачей. Таким образом, даже лучшие современные ИИ-ассистенты способны лишь упрощать и ускорять реализацию стандартных программных решений в контексте конкретного проекта, но в специализированных областях не могут заменить опытного разработчика.

Следующим важным этапом является отладка расширений в GigaIDE Cloud. Я начал с загрузки в расширение небольших тестовых репозиториев. Отладка расширения запускается из базового инстанса IDE. В новой вкладке браузера автоматически создаётся дополнительный инстанс IDE для отладки фронтенда расширения. Стандартным способом отладки фронтенда является инструмент "Developer: Open Webview Developer Tools", но в GigaIDE Cloud он недоступен. Альтернатива — это отладка через стандартный DevTools в браузере. К сожалению, этот вариант демонстрирует очень нестабильную работу — как правило, дополнительный инстанс падает через 10–15 минут после запуска. Это приводит к потере контекста, необходимости повторного запуска процесса, заставляет разработчика спешить во время отладки и создаёт чувство нестабильности системы.

При длительной работе в облачных инстансах GigaIDE Cloud наблюдается следующее:

1. Часто появляются отвлекающие сообщение об обновлениях системы.

2. Примерно раз в 2 дня у облачного инстанса слетает авторизация в GIT, и, как следствие, перестают работать команды git pull, git push.

3. Примерно раз в 3 дня облачный инстанс непоправимо ломается, в результате теряются все незалитые в репозиторий изменения.

Перечисленные выше проблемы проявляются на фоне необходимости постоянно ставить на паузу и перезапускать инстанс IDE, чтобы сэкономить часы хостинга. В противном случае весь бесплатный месячный лимит в облаке израсходуется за несколько дней.

Последнее испытание для GigaIDE Cloud — это тестирование расширения на крупных проектах. GitVerse имеет зеркало для нескольких тысяч популярных Open source проектов с GitHub. Для тестирования я делаю форки с интересных мне проектов, открываю их в дополнительном инстансе GigaIDE Cloud в отладке, настраиваю специфичные для моего расширения ignore-фильтры и заливаю их в мой форк, чтобы исходники проекта отображались в расширении оптимальным образом. Для проекта three.js мне удалось сделать форк и открыть его для тестирования с моим расширением в GigaIDE Cloud. При попытке форкнуть более крупный проект, например, godot в GitVerse возникает ошибка «сервис временно недоступен», и форк не создаётся. В итоге, чтобы во время тестирования не сталкиваться с багами и ограничениями платформы, я решил форкать все нужные мне репозитории непосредственно с GitHub и открывать их в приложении Cursor на десктопе.

Особенности работы с Cursor

GitVerse предоставляет все необходимые возможности для подключения к репозиториям из Cursor и любой другой IDE с аналогично устроенной интеграцией GIT. Я предпочитаю доступ к удалённому репозиторию по SSH, для этого копирую публичный ключ своего рабочего компьютера из "~/.ssh/id_rsa.pub" в хранилище ключей. Теперь можно клонировать репозиторий по SSH-ссылке и открывать его в локальной IDE:
cd ~/GitVerse
git clone ssh://git@gitverse.ru:2222/knyte-foundation/knyte-space-svg.git

Cursor — это приложение для десктопа, созданное на базе Electron и VS Code, доступно для всех основных десктопных ОС, имеет интеграции со всеми передовыми ИИ моделями от Claude до DeepSeek, в бесплатной версии доступно из России без ограничений. Сразу после регистрации аккаунта на сайте Cursor пользователю выдаётся Trial-период на 14 дней. Когда он заканчивается, в приложении отключается только автодополнение кода по клавише Tab. На мой взгляд, оно чаще мешает, чем помогает. А вот реально полезная возможность пользоваться премиальными ИИ-ассистентами остаётся. В месяц можно сделать не более 50 бесплатных запросов, но учитывая ограниченную сферу применения ИИ-ассистентов, мне этого достаточно.

Тем, у кого есть желание и возможность пользоваться ИИ-ассистентом на платной основе, может быть интересен MAX режим использование ИИ моделей. Для его активации необходимо активировать базовую подписку за $20, и далее платить отдельно за каждый MAX-запрос. Например, для Claude 3.7 Sonnet MAX стоимость одного запроса средней сложности может составлять порядка $10. Главное и единственное отличие MAX-запросов от стандартных — это гораздо больший размер контекста, до 200 000 токенов, что в среднем соответствует кодовой базе размером 1 ГБ. Для понимания масштабов приведу размеры для популярных Open source проектов:

• godot — 0.26 ГБ

• node — 0.57 ГБ

• linux — 1.32 ГБ

Как возможное практическое применение MAX-запросов, можно открыть в Cursor большой коммерческий проект, и попросить изменить нотацию с camel case на snake case. В течение нескольких минут и за несколько долларов результат будет получен. Если делать то же самое вручную, уйдёт не один десяток человеко-часов. Но если, например, в режиме MAX попросить Cursor переписать linux с языка C на Rust с соблюдением всех современных стандартов работы с памятью, то никакой ИИ-ассистент не справится.

Параллельно с Claude я также использую GigaCode из GigaIDE Desktop для простых запросов, на которые нет смысла тратить ограниченные вызовы Claude.

Выводы

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

Профессиональные разработчики, нацеленные на крупные Open source проекты, на коммерческие проекты, на развитие экосистемы через плагины, скорее всего, почувствуют, что на данном этапе возможностей GitVerse им не хватает. Например, для своего проекта, я ожидал увидеть локализованный отечественный маркетплейс расширений и плагинов для GigaIDE с авторизацией по Сбер ID, продажей/покупкой ассетов за СберСпасибо и аптаймом 99.9% (кто следил за состоянием инфраструктуры Eclipse в апреле 2025, поймёт запрос на аптайм).

Тем не менее молодой GitVerse, по моему мнению, показывает хорошую динамику развития и высокое качество продукта, имеет все шансы в течение нескольких месяцев укрепить свои позиции в качестве экосистемы — альтернативы для GitHub. А может быть, предложит пользователям такие концептуальные возможности, которых нет ни на одной подобной платформе, и откроет пост-ИИ эру в программировании.