Сравнение Git и Subversion (SVN)
Сегодня новые проекты почти всегда стартуют на Git, но в корпоративных и legacy-средах ещё встречается Subversion (SVN). Обе системы решают задачу версионирования, но по-разному: SVN держит "истину" на сервере, Git — у каждого разработчика полная копия истории. Понимание отличий помогает при миграции, интеграции со старым билд-сервером и чтении документации 2000‑х.
Начните с 4.13 / Основы Git и архитектуры Git.
SVN здесь — для контекста и сравнения, не как рекомендация для нового проекта.
Сравнение Git и Subversion (SVN)
Отличия Git и SVN
В некоторых случаях используется SVN (Apache Subversion) — централизованная система контроля версий: без доступа к серверу нет ни истории, ни нормального commit.
Доступ к SVN осуществляется через протоколы:
svn://(собственный протокол);http://илиhttps://(через веб-сервер);file://(локальный доступ).
В SVN вся история хранится на сервере, и разработчики имеют только рабочую копию (checkout). Команды похожи по смыслу на Git — получить код, обновиться, отправить изменения — но модель прав и веток другая.
Play ITЗагрузка интерактивного демо…
| Характеристика/команда | SVN | Git |
|---|---|---|
| Архитектура | Централизованная | Децентрализованная |
| Полная история | На сервере | У каждого разработчика |
| Работа офлайн | Нет | Да (commit локально, push позже) |
| Ветвление | Медленное (копируются папки на сервере) | Быстрое (указатели на коммиты) |
| Конфликты | Чаще (блокировки файлов) | Реже (слияние через коммиты) |
| Размер репозитория | Может быть большим на сервере | Компактный (дельта, packfile — Особенности работы с репозиториями в Git) |
| Клонирование репозитория | svn checkout <URL> | git clone <URL> |
| Обновление локальной копии | svn update | git pull (fetch + merge) |
| Отправка изменений | svn commit | git push |
| Добавление файла | svn add <file> | git add <file> |
| Удаление файла | svn delete <file> | git rm <file> |
| Фиксация изменений | svn commit -m "message" | git commit -m "message" |
| Слияние веток | svn merge <URL> | git merge <branch> |
| Создание ветки | svn copy <URL>/trunk <URL>/branches/<name> | git branch <name> + git push |
| Переключение ветки | svn switch <URL>/branches/<name> | git checkout <branch> / git switch |
| Просмотр истории | svn log | git log |
| Отмена изменений | svn revert <file> | git restore <file> |
| Метки (теги) | svn copy trunk → tags/v1.0 | git tag v1.0 |
| Игнорирование файлов | svn:ignore | .gitignore |
| Конфликты | svn resolve | git mergetool |
Когда ещё встречают SVN
- Государственные и крупные enterprise-проекты с сертифицированным SVN-сервером.
- Старые монолиты (1С, Delphi, внутренние CMS), где CI заточен под
svn update. - Бинарные деревья с lock-моделью — в SVN можно заблокировать файл на запись (
svn lock), чтобы второй разработчик не правил его параллельно — в Git блокировок нет, нужны договорённости и мелкие коммиты.
Минусы lock-модели: забытый lock блокирует команду; плюс — меньше конфликтов в огромных бинарниках без merge.
Миграция SVN → Git
Типовой путь для сохранения истории:
- Экспорт истории инструментом
git svn cloneилиsvn2git. - Проверка веток и тегов (в SVN тег — это копия каталога, в Git — указатель на commit).
- Публикация в GitHub/GitLab/GitVerse (Gitverse - отечественная альтернатива Git, SourceCraft - отечественная альтернатива Git) и перенастройка CI (DevOps).
После миграции команда учится не полагаться на "единственный сервер" как на единственный бэкап: push в remote + политика веток (Модель ветвления GitFlow или GitHub Flow).
Что выбрать для нового проекта
| Критерий | Предпочтение |
|---|---|
| Новый веб/мобильный/backend | Git |
| Нужны частые ветки и PR | Git |
| Жёсткий аудит central server only | SVN возможен по политике, но Git + self-hosted GitLab тоже закрывает требование |
| Огромные бинарники без LFS | Оценить Git LFS или SVN lock; смотреть размер и CI |
Подробнее о хранении и передаче объектов Git — Особенности работы с репозиториями в Git; о рисках деструктивных команд — Опасные скрипты.
Один день разработчика — SVN и Git рядом
SVN (legacy):
svn checkout https://svn.company.ru/repo/trunk myapp
cd myapp
# правки
svn status
svn update # подтянуть чужие
svn commit -m "Fix login"
Git (новый сервис):
git clone git@gitlab.company.ru:team/new-service.git
cd new-service
git switch -c fix/login
# правки
git commit -am "fix: login validation"
git push -u origin fix/login
При миграции монолита часто месяцы живут параллельно: старый модуль в SVN, новый микросервис в Git. Документируйте, где источник правды для каждого компонента.