Критерии выбора СКВ

Выбор СКВ, удовлетворяющей требованиям разработчиков зависит от нескольких вещей, включающих в себя следующее:

ѕ типы файлов, с которыми придется работать;

ѕ люди, которые будут работать с СКВ;

ѕ операционная система, которая будет использована.

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

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

Распределённые системы управления версиями — это СКВ, главной парадигмой которых является локализация данных каждого разработчика проекта. Иными словами, если в централизованных СКВ все действия, так или иначе, зависят от центрального объекта (сервер), то в распределенных СКВ каждый разработчик хранит собственную ветвь версий всего проекта. Удобство такой системы в том, что каждый разработчик имеет возможность вести работу независимо, время от времени обмениваясь промежуточными вариантами файлов с другими участниками проекта. Рассмотрим эту особенность, продолжая предыдущий пример.

У каждого разработчика на машине есть свой локальный репозиторий — место хранения версий файлов. Работа с данными проекта реализуется над вашим локальным репозиторием, и для этого необязательно поддерживать связь с остальными (пусть даже и главными) ветвями разработки. Связь с другими репозиториями понадобится лишь при изменении/чтении версий файлов других ветвей. При этом каждый участник проекта задает права собственного хранилища на чтение и запись. Таким образом, все ветви в распределенных СКВ равны между собой, и главную из них выделяет координатор. Отличие главной ветви лишь в том, что на неё мысленно будут равняться разработчики.

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

Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:

ѕ Надежность;

ѕ Гибкость;

ѕ Высокая скорость работы;

ѕ Высокую производительность.

ѕ Прекрасная интеграция git и Subversion при помощи git-svn (в Mercurial есть hgsvn, но git-svn более удобный);

ѕ Управление контентом, а не управление файлами. Это значит, что git в состоянии отследить без дополнительной подсказки со стороны пользователя, когда данные переносятся из одного файла в другой, а также когда файлы переименовываются.

Работа с ветками — очень легкая процедура в git, все необходимые механизмы сконцентрированы в одной команде.