Виды систем контроля версий
Обычно в системах контроля версий хранят исходный код программ, но также можно хранить и файлы других типов.
Если вы графический или веб-дизайнер и хотели бы хранить каждую версию изображения или макета, то пользоваться системой контроля версий будет правильным решением.
VCS даёт возможность:
- возвращать отдельные файлы к прежнему виду;
- возвращать к прежнему состоянию весь проект;
- просматривать происходящие со временем изменения;
- определять, кто последним вносил изменения во внезапно переставший работать модуль, кто и когда внёс в код какую-то ошибку.
Вообще, если, пользуясь VCS, вы всё испортите или потеряете файлы, всё можно будет легко восстановить. Вдобавок, накладные расходы за всё, что вы получаете, будут очень маленькими.
Можно просто копировать проект в другой каталог, такой подход часто применяется из-за своей простоты, но имеет множество недостатков:
- избыточность (дублируется весь код, а не только изменения);
- нет механизмов для распределения работы между несколькими разработчиками;
- нет данных о том что именно изменилось (обычно пишут history файл с общей информацией об изменениях).
Локальные системы контроля версий
Многие предпочитают контролировать версии, просто копируя файлы в другой каталог (как правило добавляя текущую дату к названию каталога). Такой подход очень распространён, потому что прост, но он и чаще даёт сбои. Очень легко забыть, что ты не в том каталоге, и случайно изменить не тот файл, либо скопировать файлы не туда, куда хотел, и затереть нужные файлы.
Чтобы решить эту проблему, программисты уже давно разработали локальные VCS с простой базой данных, в которой хранятся все изменения нужных файлов.
Схема локального контроля версий:
Одной из наиболее известных VCS такого типа является rcs (Revision Control System). Эта утилита основана на работе с наборами патчей между парами версий (патч — файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.
Централизованные системы контроля версий
Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (англ. Centralized Version Control System, CVCS). В таких системах, например Apache Subversion (подробнее на русском на habr-е) и Perforce Helix (подробнее на русском на habr-е, так как их сайт недоступен в РФ), есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.
Такой подход имеет множество преимуществ, особенно перед локальными VCS. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать CVCS намного легче, чем локальные базы на каждом клиенте.
Схема централизованного контроля версий:
Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный — централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё — всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей. Локальные системы контроля версий подвержены той же проблеме: если вся история проекта хранится в одном месте, вы рискуете потерять всё.
Распределённые системы контроля версий
И в этой ситуации в игру вступают распределённые системы контроля версий (англ. Distributed Version Control System, DVCS). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий (репозиторий, в простонародье репа, это место, где хранятся и поддерживаются какие-либо данные). При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.
Схема распределённой системы контроля версий:
Кроме того, в большей части этих систем можно работать с несколькими удалёнными репозиториями.
На сегодняшний день стандартом де-факто стала распределенная система контроля версий - Git, но в старых больших проектах вполне могут встретиться устаревшие VCS (например, популярная в свое время Subversion).
Сравнение
Локальные VCS
Преимущества:
- Позволяет хранить историю изменения файлов локально, без интернета.
- Вы независимы от сторонних серверов.
Недостатки:
- Вы можете потерять все файлы, если с вашем компьютером что-то случится.
- Вы не можете работать в команде, поскольку репозиторий доступен только вам.
Централизованные VCS
Преимущества:
- Вы можете работать в команде с другими разработчиками.
- Ваше начальство видит, чем вы занимаетесь.
- У администратора есть четкий контроль, кто и что может делать. Администрировать центральную VCS намного проще, чем локальные на каждой машине.
Недостатки:
- Все данные хранятся только на одном сервере. Если он выключится, то работу всей компании парализует.
- Если с сервером что-то случится, а копий данных нет, то весь проект может быть потерян.
- Для работы необходим хороший интернет на протяжении целого дня.
Распределенные VCS
Пр еимущества:
- Работа компании теперь не зависит от работы сервера. Если сервер отключится, то каждый сотрудник продолжит работу с локальной копией репозитория, а после загрузит ее на сервер.
- Можно работать с несколькими удаленными репозиториями, делиться кодом с другими людьми и коллаборировать целыми компаниями.
Недостатки:
- Отсутствие блокировок.
- Неудобства при работе с большими репозиториями.
- Сложно полностью удалить что-то из репозитория.
- Сложное администрирование.
- Сложнее в использовании и понимании, чем централизованные системы.
Атрибуция
При подготовке статьи использован материал: