Введение в системы контроля версий

При разработке программного обеспечения рано или поздно приходится вносить сложные исправления(изменения), в которых, с большой вероятностью, могут содержаться ошибки. Если проект - небольшой, то, обычно, делается его резервная копия. Но что делать, если вы сопровождаете огромный проект, состоящий из сотен и даже тысяч файлов?

Копировать каждый раз весь проект, вручную описывать версию - долго и трудоемко. Мало того, что это будет занимать слишком много места на жестком диске, так еще немудрено запутаться в версиях и использовать, вместо сохраненной правильной версии, промежуточную недоделанную версию с массой ошибок. Хорошо, если потом можно быстро откатиться на правильную версию, но ведь бывают случаи, когда, наводя порядок в архиве, удаляются единственно верные копии с последними наработками.

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

Естественным путем, сообщество разработчиков пришло к выводу о необходимости специализированного программного обеспечения, позволяющего просто и надежно сопровождать большие программные проекты. И в скором времени появилось множество программ для контроля версий (Git, CVS, Subversion, Bazaar, Monotone, Aegis и др.), позволяющих удовлетворять любые, даже самые изощренные пожелания.

Эти программы – системы контроля версий, позволяют:

1. Сохранять все этапы разработки. Внеся изменения в один или несколько файлов проекта, программист записывает изменения в репозиторий – хранилище всех версий и изменений проекта. Стоит отметить, что сохраняется не весь проект целиком, а, в целях экономии места и времени сохранения изменений (сервер с репозиторием может быть удаленным, и, если проект - очень большой, то требуется достаточно большое время для передачи всех его файлов по сети), в репозиторий добавляются только файлы, претерпевшие изменения.

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

3. Объединять изменения. Часто несколько программистов одновременно изменяют одни и те же файлы. Если изменения не пересекаются, то системы контроля версий позволяют легко и просто объединить эти изменения.

4. Решать конфликты. Если несколько человек изменили один и тот же участок кода, то, автоматически, объединить такие изменения - невозможно. Обычно, системы контроля версий предоставляют собой инструменты, позволяющие вручную внести необходимые правки в тест программ, чтобы объединить конфликтующие части кода.

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

6. Сопровождение нескольких направлений развития программного обеспечения. Не всегда можно сразу сохранять внесенные изменения. Часто приходится достаточно долго разрабатывать и отлаживать отдельные правки прежде, чем их можно объединить с основным программным обеспечением. В этом случае многие системы контроля версий позволяют организовывать параллельные ветки по контролю нескольких направлений развития программного обеспечения, быстро переключаться между ними, а затем объединять их в единое целое.

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

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

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

Централизованные системы, такие как CVS и Subversion, для сохранения всех рабочих файлов контролируемого проекта использует репозиторий, размещенный на отдельном сервере.

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

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

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

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

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

Загрузка изменений в основной репозиторий будет производиться, когда все они отлажены и избавлены от ошибок.

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

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

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