О системе контроля версий

Локальные системы контроля версий

Для того чтобы контролировать версии, многие люди копируют файлы в другой каталог. Возможно даже, если они достаточно сообразительны, копируют в другой каталог с отметкой времени. Такой способ распространен из-за своей простоты, однако он невероятно ненадежен. Можно легко забыть, в какой папке вы находитесь, и случайно записать не в тот файл или скопировать не те файлы, которые вы хотели.

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

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

Хранилище конфигурации - централизованная система контроля версий

Следующая серьезная проблема, с которой сталкиваются люди, это необходимость взаимодействовать с другими разработчиками. Для ее решения были придуманы централизованные системы контроля версий (Centralized Version Control System). Примером такой системы является, например, хранилище конфигурации, которое использует платформа «1С:Предприятие», а также системы CVS, Subversion и Perforce. Они имеют один сервер, содержащий все версии файлов, и некоторое количество клиентов, которые извлекают файлы из этого центрального хранилища. Применение централизованных систем контроля версий являлось стандартом на протяжении многих лет.

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

Однако данный подход имеет и серьезные минусы. Самый очевидный минус — это единая точка отказа, которой является центральный сервер. Если этот сервер выйдет из строя на час, то в течение этого времени никто вообще не сможет ни взаимодействовать друг с другом, ни сохранить изменения в файле, с которым он работает. Если жесткий диск, где хранится центральная база данных, окажется поврежден, а резервных копий не будет, то вы потеряете всю историю проекта, за исключением единичных снимков репозитория, которые сохранились на локальных машинах разработчиков. Кстати, локальные системы контроля версий страдают от той же самой проблемы: поскольку вся история проекта хранится в одном месте, вы рискуете потерять все.

Распределенные системы контроля версий

Здесь в игру вступают распределенные системы контроля версий (Distributed Version Control System. Это такие системы, как Git, Mercurial, Bazaar или, например, Darcs. В них клиенты не просто извлекают последний снимок всех файлов (состояние файлов на определенный момент времени) — они полностью копируют репозиторий, включая всю его историю. Такая операция называется клонированием. В этом случае, если какой-нибудь сервер, с которым взаимодействуют разработчики, выйдет из строя, любой клиентский репозиторий может быть скопирован на другой сервер для продолжения работы. Каждый клон (копия) репозитория является полной резервной копией всех данных.

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