- Андрей Куманяев/
- Git: руководства и команды/
- Распределённые системы контроля версий: Git, SVN, CVS — сравнение/
Распределённые системы контроля версий: Git, SVN, CVS — сравнение
Системы контроля версий (VCS) прошли путь от централизованных решений (CVS, SVN) к распределённым (Git, Mercurial). Понимание этой эволюции помогает лучше понять, почему Git устроен именно так, и почему он вытеснил предшественников.
CVS: первопроходец (1986) #
Concurrent Versions System — первая широко используемая система контроля версий. Появилась в 1986 году.
Архитектура CVS — централизованная:
Центральный сервер (репозиторий)
↑↓
Разработчик 1 (рабочая копия)
Разработчик 2 (рабочая копия)
Разработчик 3 (рабочая копия)
Все изменения хранятся на центральном сервере. У разработчиков — только рабочие копии файлов.
Основные проблемы CVS:
- Нет атомарных коммитов: при сбое сервера коммит мог завершиться частично
- Нельзя переименовывать файлы без потери истории
- Ветвление медленное и сложное
- Каждый коммит требует подключения к серверу
- Нет глобального номера версии (версии отдельных файлов)
- Конфликты при одновременной работе нескольких человек
CVS считался стандартом в 1990-х, но к 2000-м его ограничения стали критическими.
SVN: улучшение CVS (2000) #
Subversion создавался с явной целью «CVS, но правильно». Выпущен в 2000 году Apache Software Foundation.
Что SVN исправил по сравнению с CVS:
✓ Атомарные коммиты (commit или полностью завершается, или нет)
✓ Переименование файлов с сохранением истории
✓ Глобальный номер ревизии (r1, r2, r3...)
✓ Лучшая обработка бинарных файлов
✓ Версионирование метаданных (properties)
Что SVN не решил:
✗ Всё ещё централизованный: все операции требуют сервера
✗ Ветвление всё ещё медленнее, чем в Git
✗ При недоступности сервера — нельзя работать
✗ Merge-история ненадёжна
✗ Одна точка отказа — сервер
SVN был популярен в 2000-е и используется в некоторых компаниях до сих пор, особенно в корпоративной среде.
Git: революция распределённой VCS (2005) #
Git создан Линусом Торвальдсом в 2005 году для разработки ядра Linux. Предыдущая VCS — BitKeeper — перестала быть бесплатной для открытых проектов. За две недели Торвальдс написал первую версию Git.
Архитектура Git — распределённая:
Удалённый репозиторий (GitHub/GitLab)
↑↓ ↑↓
Разработчик 1 Разработчик 2
(полная копия) (полная копия)
↕ ↕
Локальный Локальный
репозиторий репозиторий
У каждого разработчика — полная копия репозитория со всей историей.
Ключевые преимущества распределённой архитектуры:
✓ Большинство операций выполняется локально (быстро)
✓ Работа без сети (commit, log, diff, branch)
✓ Нет единой точки отказа
✓ Можно работать в оффлайне
✓ Каждый клон — это резервная копия
Сравнение рабочих процессов #
SVN (централизованный):
# Получить последние изменения с сервера
svn update
# Зафиксировать изменения (требует сервер)
svn commit -m "Fix bug"
# Нельзя работать без сервера
Git (распределённый):
# Работать локально без сети
git commit -m "Fix bug" # локальный коммит
# Синхронизировать с сервером когда нужно
git push origin main
# Можно делать много локальных коммитов, потом push
Производительность #
Операция CVS/SVN Git
──────────────────────────────────────────
Commit Медленно* Мгновенно
Log (история) Медленно* Быстро (локально)
Diff Медленно* Быстро (локально)
Branch (создать) Секунды-минуты Мгновенно
Merge Сложно Быстро
Clone — Полная копия
* требует запроса к серверу
Ветвление: ключевое различие #
В SVN ветка — это отдельная копия папки на сервере:
SVN структура:
/trunk — основная ветка
/branches/
feature-1/ — копия trunk
hotfix/ — копия trunk
/tags/
v1.0/ — копия trunk для тега
В Git ветка — лёгкий указатель:
# В Git создание ветки — одна строчка, мгновенно
git branch feature-1
# Git хранит только указатель (SHA-хеш), не копию файлов
# Ветка занимает ~40 байт
Именно поэтому в Git принято создавать ветки для каждой задачи, а в SVN это делалось реже из-за сложности.
Модели безопасности #
SVN:
- Коммит = отправка на сервер
- При потере сервера — потеря истории
- Доступ: по логину/паролю или LDAP
Git:
- Каждый клон — полная копия истории
- Данные защищены SHA-1/SHA-256 хешами
- Любая модификация истории заметна
- Доступ: SSH ключи или токены
Миграция с SVN на Git #
Многие команды переходят с SVN на Git. Процесс:
# Установить git-svn (обычно входит в Git)
# Клонировать SVN репозиторий
git svn clone https://svn.example.com/repos/project \
--stdlayout \
--authors-file=authors.txt \
my-project
# --stdlayout предполагает структуру trunk/branches/tags
# authors.txt: svn-login = Full Name <[email protected]>
# После клонирования — обычный Git репозиторий
cd my-project
git log --oneline
Mercurial (Hg): конкурент Git #
В 2005 году одновременно с Git появился Mercurial — тоже распределённая VCS. Долгое время использовался Facebook, Bitbucket поддерживал оба.
Mercurial vs Git:
- Похожая распределённая архитектура
- Проще в изучении
- Менее гибкий (нельзя переписывать историю по умолчанию)
- Git победил за счёт GitHub и экосистемы
- Bitbucket убрал поддержку Mercurial в 2020
Часто задаваемые вопросы #
Когда ещё использовать SVN вместо Git? SVN может быть предпочтителен для: очень больших бинарных файлов (игровые ассеты), когда нужен fine-grained доступ к отдельным папкам, legacy enterprise-систем. Для большинства задач Git предпочтительнее.
Можно ли использовать Git с централизованным workflow? Да. Git можно использовать централизованно (только один remote, прямые пуши в main). Это называется Centralized Workflow — компромисс для команд, привыкших к SVN.
Что такое DVCS? Distributed Version Control System — распределённая система контроля версий. Git и Mercurial — DVCS. SVN и CVS — централизованные (CVCS).
Почему Git выиграл у Mercurial? Преимущественно из-за GitHub (запущен в 2008) и открытого исходного кода ядра Linux. GitHub создал сетевой эффект — большинство open source перешло на Git, за ним последовали компании.
Заключение #
Распределённые системы контроля версий (Git) превзошли централизованные (SVN, CVS) по скорости, гибкости и надёжности. Каждый разработчик имеет полную копию репозитория, большинство операций выполняются локально. Git создан в 2005 году и стал стандартом индустрии. Подробнее о самом Git — что такое Git и зачем он нужен.