Программа для контроля версий файлов
Система контроля версий – это обязательный инструмент в арсенале программиста любого уровня: от новичка, который только осваивается в профессии, до тимлида, чей опыт исчисляется многими годами и проектами.
И если профи хорошо представляют себе задачи и возможности такой системы, то начинающим необходимо дать некоторые объяснения. Впрочем, иногда и опытные программисты совершают ошибки при работе с системой.
В нашей статье мы расскажем, зачем нужен данный инструмент, как им правильно пользоваться и разберем некоторые ошибки, которые допускают чаще всего.
Принцип работы системы контроля версий
Пожалуй, многие представляют себе, каким образом вносятся изменения в тот или иной проект в процессе работы. То есть, тут стоит задача не потерять существующую работоспособную версию проекта. Для этого обычно создается новая папка (чаще всего ее так и называют «Новая папка», дополняя имя, к примеру, датой или парой символов), в которую вы копируете имеющуюся версию и все дальнейшие изменения производите уже именно с ней.
Подобных папок может набраться довольно много. Из-за этого в какой-то момент усложняется откат к предыдущим версиям, труднее становится контролировать и упорядочивать вносимые изменения и т.д. А если проект ведут несколько специалистов, картина усугубляется.
Принцип работы системы контроля версий
Системы контроля версий (СКВ или VCS) разработаны специально для того, чтобы максимально упростить и упорядочить работу над проектом (вне зависимости от того, сколько человек в этом участвуют). СКВ дает возможность видеть, кто, когда и какие изменения вносил; позволяет формировать новые ветви проекта, объединять уже имеющиеся; настраивать контроль доступа к проекту; осуществлять откат до предыдущих версий.
Задачи для системы контроля версий
В целом задачи для системы контроля версий уже описаны выше, но можно пояснить еще, для тех, кто сталкивается с термином впервые. Для наглядности представьте, что работа над проектом – это игра, которую нужно пройти, двигаясь от одной контрольной точки – к другой (это и будут промежуточные версии проекта).
Получите подборку бесплатно (pdf 2,5 mb)
Пусть, к примеру, разработку плагина для WordPress ведет один специалист. Заказчик вносит в ТУ требование обязательно использовать Git либо аналоги. Для него в будущем важно наличие свободного доступа к данным.
Сформировав репозиторий, программист занимается плагином. Первую рабочую версию продукта он оставляет в основной ветке. Каждый раз, сделав изменение, обозначает новый коммит (контрольную точку). А когда возникает необходимость в масштабном изменении, образует параллельные ветки.
Задачи для системы контроля версий
Но чего можно ожидать, если программист на своем компьютере не использовал систему контроля версий и не сохранял создаваемые промежуточные копии плагина? Специалист будет переделывать проект практически заново. Возможно, ему и удастся внести нужные изменения, не нарушив основную логику, но это будет очень и очень сложно.
А теперь представьте, что работу над плагином ведут несколько человек. Тогда применение СКВ даже не обсуждается. Это позволит каждому разработчику, отделившись от основной ветки, выполнять свой конкретный круг задач. После чего специалисты проверят код на ошибки и объединят вместе все части проекта.
Работа в системе контроля версий дает возможность сохранять промежуточные варианты проекта, плюс это еще и помогает справляться с проблемами в случае их возникновения. Когда, например, несколько программистов, работающих над одной опцией, одновременно сбросят в репозиторий созданные версии, то система в автоматическом режиме займется устранением конфликта.
Если система не справится с проблемой, то разработчики получат информацию об этом и вручную всё «подчистят». В конечном счете, именно программист контролирует и процесс, и окончательный результат.
Вот перечень задач, выполняемых системой контроля версий файлов:
- Сохранение исходного кода. Информация сваливается на удаленный сервер и в репозитории остаются даже файлы, удаленные с компьютера разработчика.
- Возможность привлекать группу программистов, не покупая отдельно специальные инструменты для командной работы. Каждый свою задачу на персональном компьютере, обновляя файлы, когда это нужно.
- Отмена внесенных изменений. Всегда есть возможность вернуться к контрольной точке, провести ревью исходного кода и текущего, а затем обновить основную ветку.
- Распределенная работа над проектом. То есть, программисты могут создавать видоизмененный плагин, пока основная его версия спокойно функционирует на сайте.
Команда GeekBrains совместно с международными специалистами по развитию карьеры подготовили материалы, которые помогут вам начать путь к профессии мечты.
Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!
Все мы знаем и любим Git. И, конечно же, были придуманы его аналоги для управления версиями данных, чтобы эксперименты с данными были воспроизводимыми, а действия команд — согласованными. Сегодня, в преддверии старта нового потока курса по Data Science, делимся с вами материалом о сравнении нескольких систем контроля версий. Подробности сравнения — как обычно, под катом.
Используете вы логистическую регрессию или нейронную сеть, в любом случае все модели требуют данных для обучения, тестирования и развертывания. Создание используемых моделями наборов данных и управление ими требуют много времени и пространства, а кроме прочего, могут быстро запутаться из-за того, что несколько пользователей изменяют и обновляют данные. Это, в свою очередь, приводит к неожиданным результатам, поскольку дата-сайентисты продолжают выпускать новые версии моделей, но тестируют их на разных наборах данных.
Но множество дата-сайентистов могли бы заниматься подготовкой и разработкой моделей на основе одних тех же наборов учебных данных. Это приведёт к большому количеству тонких изменений в наборе данных, которые, в свою очередь, после развёртывания моделей могут привести к неожиданным результатам. В этом посте обсуждаются проблемы, приходящие с управлением данными, и даётся обзор топовых инструментов для машинного обучения и управления версиями данных.
Проблемы управления данными
Управление наборами данных и таблицами для Data Science и моделей машинного обучения требует от дата-сайентистов и инженеров значительных временных затрат. Всё, начиная с управления хранилищем, версиями данных и заканчивая доступом, требует большого ручного труда.
Пространство хранилища
Обучающие данные могут занимать значительное место в репозиториях git. Это связано с тем, что git разработан для отслеживания изменений в текстовых, но в небольших бинарных файлах. Поэтому, когда наборы тренировочных данных содержат большие аудио- или видео-файлы, в дальнейшем это приносит много проблем. Каждое изменение в наборе обучающих данных приводит к дублированию набора данных в истории репозиториев. Такое дублирование не только делает репозиторий большим, но и значительно замедляет его клонирование и перебазирование (git rebase).
Управление версиями данных
В попытке управлять версиями (будь то код или пользовательский интерфейс) даже среди технарей широко распространена тенденция «управлять версиями», добавляя номер версии или слово в конец имени файла.
В контексте данных это означает, что проект может содержать файлы data.csv, data_v1.csv, data_v2.csv, data_v3_finalversion.csv и т.д. Эта плохая привычка — не просто клише: с плохих привычек версионирования на самом деле начинают большинство разработчиков, дата-сайентистов и экспертов пользовательского интерфейса.
Многопользовательская среда
При работе в производственной среде одна из самых больших проблем — работа с другими дата-сайентистами. Если вы не используете какую-то форму управления версиями в среде совместной работы, файлы удаляются, изменяются и перемещаются, а вы не знаете, кто и что сделал. Кроме того, сложно вернуть данные в исходное состояние. Когда речь заходит об управлении моделями и наборами данных, это одна из самых больших проблем.
Обзор лучших альтернатив в управлении версиями данных
Версионирование данных — один из ключей к автоматизации разработки модели машинного обучения в разрезе команды. Очень сложно разработать собственную систему для управления процессом, но, к счастью, в этом нет необходимости. Давайте посмотрим на 6 великолепных инструментов с открытым исходным кодом, которые ваша команда может применять, чтобы упростить управления данными и версионирование.
DVC, или Data Version Control, — это один из многих доступных инструментов с открытым исходным кодом, упрощающих работу с проектами Data Science и ML.
Используется подход Git'а в том смысле, что дает интерфейс командной строки, который настраивается в несколько простых шагов. DVC, как предполагает его название, фокусируется не только на версионировании данных. Инструмент помогает командам управлять конвейерами и моделями машинного обучения. В конце концов, DVC способствует согласованности вашей команды и воспроизводимости ваших моделей.
Преимущества
- Лёгкий, исходники открыты, подходит для всех основных облачных платформ и типов хранилищ данных.
- Гибкий, независимый от формата и фреймворка, лёгкий в применении.
Недостатки
- Контроль версий DVC тесно связан с управлением конвейером. Это означает, что, если ваша команда уже применяет другой инструмент конвейера данных, будет дублирование.
- DVC лёгкий, это означает, что вашей команде, возможно, придётся вручную разработать дополнительные функции.
Delta Lake
Delta Lake — это слой хранилища с открытым исходным кодом, помогающий улучшить состояние озёр данных. Это делается предоставлением транзакций ACID, версионированием данных, управлением метаданными и управлением версиями данных. Инструмент находится ближе к слою абстракции озёр данных, заполняя пробелы там, где большинство озёр данных ограничены.
Преимущества
- Предлагает множество функций, которые могут не входить в вашу систему хранения данных, например ACID-транзакции или эффективное управление метаданными.
- Снижает необходимость в ручном управлении версиями данных и ручном решении других связанных с данными вопросов, позволяя разработчикам сосредоточиться на построении продуктов поверх озёр данных.
Недостатки
- Delta Lake часто бывает перегибом для большинства проектов: инструмент был разработан для работы со Spark на больших данных.
- Требуется специальный формат данных, а это означает, что инструмент теряет в гибкости и зависим в отношении текущих форматов.
- Основная задача инструмента — действовать в качестве скорее уровня абстракции данных, а это может быть не тем, что нужно вашей команде, и также может игнорировать разработчиков, которым нужно решение легче.
Git LFS
Git LFS — разработанное рядом разработчиков расширение Git'а с открытым исходным кодом. Это ПО предназначено для устранения больших файлов, которые могут быть добавлены в ваше хранилище (например фотографий и наборов данных) с помощью указателей. Указатели легче, они указывают на хранилище LFS. Таким образом, когда вы отправляете изменения из вашего репозитория в основной, обновление не занимает много времени или места. Это очень легковесный вариант для управления данными.
Преимущества
- Легко интегрируется в рабочие процессы разработки большинства компаний.
- Использует те же права доступа, что и репозиторий, поэтому нет необходимости в дополнительном управлении правами.
Недостатки
- Git LFS для хранения ваших данных требует выделенных серверов. Это, в свою очередь, в конечном счёте приводит к тому, что ваши группы дата-сайентистов оказываются заблокированными, а также к увеличению объема инженерной работы.
- Серверы Git LFS не предназначены для масштабирования в отличие от DVC, который хранит данные в более общем и легко масштабируемом хранилище объектов, например S3.
Очень специфичен и может потребовать использования ряда других инструментов для иных этапов рабочего процесса в Data Science.
Pachyderm
Pachyderm — одна из немногих платформ для сбора данных в этом списке. Цель Pachyderm — создать платформу, позволяющую легко воспроизводить результаты моделей ML, управляя всем рабочим процессом обработки данных. В этом отношении Pachyderm — Docker для данных.
Pachyderm использует контейнеры Docker для упаковки вашей среды выполнения. Это позволяет легко воспроизвести результат. Сочетание версионирования данных и Docker дает специалистам Data Science и командам DevOps легко развёртывать модели и обеспечивать их согласованность. Компания Pachyderm взяла на себя обязательства по Биллю о правах в Data Science, в котором изложены основные цели продукта: воспроизводимость, знание истории данных, сотрудничество, инкрементальность и автономия, а также абстрагирование инфраструктуры. Эти принципы определяют многие из особенностей продукта и позволяют командам воспользоваться преимуществ инструмента в полной мере.
Преимущества
- Базируется на контейнерах, что делает ваши среды данных портативными и лёгкими в миграции на различных вендоров облачных услуг.
- Надёжный, масштабируется от небольших до очень больших систем.
Недостатки
- Кривая обучения круче из-за большого количества подвижных частей, таких как сервер Kubernetes, необходимый для управления бесплатной версией Pachyderm.
- При наличии различных технических компонентов сложно будет интегрировать Pachyderm в уже существующую инфраструктуру.
Dolt — уникальное решение для версионирования данных. В отличие от некоторых других представленных вариантов, которые просто содержат данные о версии, Dolt — это база данных SQL с версиями в стиле Git. Но в отличие от Git'а, где в центре файлы, у Dolt в центре — таблицы. Это означает, что вы можете обновлять и изменять данные, не беспокоясь о потере изменений. Приложение ещё новое, в ближайшем будущем планируется сделать его на 100 % совместимым с Git и MySQL.
Преимущества
- Инструмент лёгкий, и его код частично открыт.
- SQL-интерфейс делает его доступнее для аналитиков данных в сравнении с более непонятными вариантами.
Недостатки
- По сравнению с другими версиями баз данных Dolt — еще не зрелый продукт.
- Dolt — это база данных, то есть вы должны перенести свои данные в Dolt, чтобы получить его преимущества.
- Dolt создан для версионирования таблиц. Это означает, что он не охватывает другие типы данных (например изображения или текст в свободной форме).
LakeFS
LakeFS позволяет командам строить повторяющиеся, атомарные и версионированные операции с данными об озёрах. На сцене LakeFS новичок, но он наносит удар. Предоставляется Git-подобная модель ветвления и управления версиями, предназначенная для работы с вашим озером данных, и она масштабируется до петабайт данных.
Подобно Delta Lake, LakeFS обеспечивает соответствие ACID в ваших озёрах данных. Однако LakeFS поддерживает как AWS S3, так и Google Cloud Storage в качестве бэкендов, а это означает, что для использования всех преимуществ не требуется использовать Spark.
Преимущества
- Предоставляет расширенные возможности, такие как ACID транзакции, для лёгкости использования облачного хранения данных (например S3 и GCS), и всё это вне зависимости от формата.
- Легко масштабируется, поддерживая очень большие озёра данных. Способен предоставить контроль версий как для среды разработки, так и для производственной среды.
Недостатки
- LakeFS — относительно новый продукт, поэтому по сравнению с другими решениями функции и документация могут меняться быстрее.
- Ориентирован на версионирование данных, а это означает, что вам потребуется использовать ряд иных инструментов для других этапов рабочего процесса Data Science.
Вам Действительно нужно управление версиями данных?
При всех преимуществах версионирования данных не всегда нужно вкладывать огромные усилия в управление ими. Например, большая часть версий данных предназначена, чтобы помочь отслеживать наборы данных, которые сильно меняются с течением времени.
К некоторым данным, таким как веб-трафик, другие данные только добавляются. Это означает, что данные добавляются, но редко изменяются. То есть версии данных, необходимых для создания воспроизводимых результатов, — это даты начала и окончания. Важно это отметить, поскольку в таких случаях, возможно, вам удастся избежать установки упомянутых выше инструментов. Вам всё равно нужно будет управлять датами начала и окончания, чтобы убедиться, что вы тестируете систему и модели на одних и тех же данных. Однако в таких случаях не обязательно фиксировать все данные в системе версионирования.
Итоги
Управление версиями данных — необходимый шаг для команд дата-сайентистов, позволяющий избежать несоответствий выходных данных. Используете ли вы Git-LFS, DVC или другой обсуждаемый инструмент, потребуется некоторая версионность данных. Эти инструменты версионирования данных могут помочь сократить объем памяти, необходимый для управления наборами данных, а также помочь отслеживать вносимые членами команды изменения. Без инструментов для версионирования данных ваш дежурный специалист может отлаживать модель в 3 часа ночи из-за проблемы, возникшей по причине несовпадения результатов моделирования. Однако всего этого можно избежать, если ваши команды специалистов по работе с данными внедрили процесс управления версиями данных.
На тот случай если вы задумали сменить сферу или повысить свою квалификацию — промокод HABR даст вам дополнительные 10% к скидке указанной на баннере.
Система контроля версий является прежде всего инструментам, а инструмент призван решать некоторый класс задач. Итак, система контроля версий – это система, записывающая изменения
в файл или набор файлов в течение времени и позволяющая вернуться позже к определенной версии. Мы хотим гибко управлять некоторым набором файлом, откатываться до определенных версий в случае необходимости. Можно отменить те или иные изменения файла, откатить его удаление, посмотреть кто что-то поменял. Как правило системы контроля версий применяются для хранения исходного кода, но это необязательно. Они могут применяться для хранения файлов совершенно любого типа.
Как хранить различные версии файлов? Люди пришли к такому инструменту как системы контроля версий не сразу, да и они сами бывают очень разные. Предложенную задачу можно решить с применением старого доброго copy-paste, локальных, централизованных или распределенных систем контроля версий.
Copy-paste
Известный метод при применении к данной задаче может выглядеть следующим образом: будем называть файлы по шаблону filename_, возможно с добавлением времени создания или изменения.
Данный способ является очень простым, но он подвержен различным ошибкам: можно случайно изменить не тот файл, можно скопировать не из той директории (ведь именно так переносятся файлы в этой модели).
Локальная система контроля версий
Следующим шагом в развитии систем контроля версий было создание локальных систем контроля версий. Они представляли из себя простейшую базу данных, которая хранит записи обо всех изменениях в файлах.
Одним из примеров таких систем является система контроля версий RCS, которая была разработана в 1985 году (последний патч был написан в 2015 году) и хранит изменений в файлах (патчи), осуществляя контроль версий. Набор этих изменений позволяет восстановить любое состояние файла. RCS поставляется с Linux'ом.
Локальная система контроля версий хорошо решает поставленную перед ней задачу, однако ее проблемой является основное свойство — локальность. Она совершенно не преднезначена для коллективного использования.
Централизованная система контроля версий
Централизованная система контроля версий предназначена для решения основной проблемы локальной системы контроля версий.
Для организации такой системы контроля версий используется единственный сервер, который содержит все версии файлов. Клиенты, обращаясь к этому серверу, получают из этого централизованного хранилища. Применение централизованных систем контроля версий на протяжении многих лет являлась стандартом. К ним относятся CVS, Subversion, Perforce.
Такими системами легко управлять из-за наличия единственного сервера. Но при этом наличие централизованного сервера приводит к возникновению единой точки отказа в виде этого самого сервера. В случае отключения этого сервера разработчики не смогут выкачивать файлы. Самым худшим сценарием является физическое уничтожение сервера (или вылет жесткого диска), он приводит к потерю кодовой базы.
Несмотря на то, что мода на SVN прошла, иногда наблюдается обратный ход — переход от Git'а к SVN'у. Дело в том, что SVN позволяет осуществлять селективный чекаут, который подразумевает выкачку лишь некоторых файлов с сервера. Такой подход приобретает популярность при использовании монорепозиториях, о которых можно будет поговорить позже.
Распределенная система контроля версий
Для устранения единой точки отказа используются распределенные системы контроля версий. Они подразумевают, что клиент выкачает себе весь репозиторий целиком заместо выкачки конкретных интересующих клиента файлов. Если умрет любая копия репозитория, то это не приведет к потере кодовой базы, поскольку она может быть восстановлена с компьютера любого разработчика. Каждая копия является полным бэкапом данных.
Все копии являются равноправным и могут синхронизироваться между собой. Подобный подход очень напоминает (да и является) репликацией вида master-master.
К данному виду систем контроля версий относятся Mercurial, Bazaar, Darcs и Git. Последняя система контроля версий и будет рассмотрена нами далее более детально.
История Git
В 2005 году компания, разрабатывающая систему контроля версий BitKeeper, порвала отношения с сообществом разработчиков ядра Linux. После этого сообщество приняло решение о разработке своей собственной системы контроля версий. Основными ценностями новой системы стали: полная децентрализация, скорость, простая архитектура, хорошая поддержка нелинейной разработки.
Заключение
Мы рассмотрели способы организации систем контроля версий, обсудили варианты решения поставленных перед этими системами задач, поговорили о преимуществах и недостатках каждого из них, познакомились с историей системы контроля версий Git.
Система контроля версий относится к процессу, касающемуся систематизации версий, объединяемых при редактировании и совместной работе. Хотя контроль версий как термин рассматривается в контексте разработки программного обеспечения, на самом деле, он необходим для профессионалов разных отраслей.
Для крупных проектов по разработке программного обеспечения системы контроля версий отслеживают множество изменений в исходном коде.
Почему так важны системы контроля версий?
Все системы контроля версий обладают следующими возможностями:
- позволяют команде программистов одновременно работать над одним и тем же проектом;
- минимизируют конфликты между разработчиками, которые работают над одним проектом;
- автоматически создают архив каждой версии, включающий в себя все изменения проекта.
Существуют разные системы управления версиями, но какие отличительные черты делают их уникальными? Перечислим три их главные группы:
- в соответствии с расположением репозитория: централизованные и распределенные;
- в соответствии с методами проверки слияния и передачи кода: блокирующие, использующие слияние до фиксации и выполняющие фиксацию до слияния;
- системы управления версиями могут выполнять небольшие операции или операции с файлами.
5 систем контроля версий с открытым исходным кодом
CVS является самой популярной и широко применяемой системой контроля версий на сегодняшний день. После выпуска в 1986 году она быстро стала общепринятым стандартом. CVS приобрела популярность благодаря простой системе поддержки файлов и ревизий в актуальном состоянии.
Существует ряд IDE для CVS , включая Xcode ( Mac ), Eclipse , NetBeans и Emacs .
- Это проверенная временем система, которая используется более трех десятилетий;
- Существует много IDE , которые используют CVS .
- Перемещение или переименование файлов не включается в обновление версии;
- Предоставление символических ссылок на файлы связано с некоторыми рисками безопасности;
- Отсутствие поддержки атомарных операций может привести к повреждению исходного кода;
- Медленные операции установления меток и ветвления;
- Слабая поддержка двоичных файлов.
Еще одна распространенная система управления версиями. Большинство проектов с открытым исходным кодом и крупные платформы, такие как Ruby , Python Apache , используют SVN . Из-за огромной популярности существует множество версий и доступных IDE .
Достоинства системы контроля версий SVN
- Новая и значительно улучшенная система, основанная на CVS ;
- Допускает атомарные операции;
- Операции в ветке проекта малозатратны;
- Доступны различные плагины IDE .
- Выдает ошибки при переименовании файлов и каталогов;
- Недостаточно команд для управления репозиторием;
- SVN работает медленнее по сравнению с другими системами управления версиями.
Благодаря распределенной форме управления без необходимости использования оригинального программного обеспечения многие проекты с открытым исходным кодом предпочитают Git .
- Почти все отрицательные черты CVS/SVN устранены;
- Высокая скорость работы распределенной системы контроля версий;
- Легкость проведения различных операций с ветками проекта;
- Пользователи могут получить доступ к полному дереву истории в режиме офлайн;
- Предлагает высоко распределенную одноранговую модель.
- Высокий порог вхождения для пользователей SVN ;
- Ограниченная поддержка Windows по сравнению с Linux .
Mercurial
Считается эффективной для крупных проектов, в которых участвует много разработчиков и проектировщиков. Mercurial – это высокопроизводительная система, предлагающая оптимальную скорость. Она также известна своей простотой и подробной документацией.
Достоинства Mercurial системы контроля версий
- Низкий порог вхождения по сравнению с Git ;
- Подробная документация;
- Распределенная модель;
- Высокопроизводительная система с отличной скоростью.
- Нельзя объединить две родительские ветки;
- Основана на расширениях, а не сценариях;
- Недостаточно гибкая, чтобы выполнять операции по умолчанию.
Bazaar
Уникальна тем, что может использоваться с распределенной и централизованной базой кода. Это делает ее универсальной системой контроля версий. Кроме этого Bazaar позволяет использовать детальный уровень управления. Ее можно легко развернуть в самых разных сценариях, что делает ее адаптивной и гибкой для всевозможных проектов.
- Идеально подходит для разнообразных проектов;
- Предоставляет гораздо более продвинутый набор команд и поддержку IDE ;
- Включает в себя настраиваемый набор функций, который подходит для разнообразных проектов.
- Является новой и недостаточно проработанной системой управления версиями;
- Отсутствует поддержка IDE .
Что касается популярности, порога вхождения, производительности и адаптивности, рассмотренные в этой статье системы контроля версий существенно превосходят другие.
Пожалуйста, оставьте свои комментарии по текущей теме материала. Мы крайне благодарны вам за ваши комментарии, лайки, подписки, отклики, дизлайки!
Пожалуйста, оставляйте ваши мнения по текущей теме статьи. За комментарии, дизлайки, подписки, отклики, лайки низкий вам поклон!
У вас появилась новая замечательная бизнес-идея, связанная с разработкой ПО? Вам нужно разработать технологически сложное решение? Или у вас большая команда программистов, работающих над одной задачей? Тогда запомните эти три слова: система контроля версий .
Если вы еще не знакомы с концепцией системы контроля версий , то вот здесь все очень наглядно показано.
Или посмотрите видео от GitHub.
Итак, какая система контроля версий подойдет для вашего проекта?
Мы сравнили несколько популярных решений, чтобы вам было проще сделать выбор.
Это узкоспециальная техническая тема. Мы постарались сделать наш обзор понятным для всех. Но если у вас нет опыта в программировании, обязательно посоветуйтесь с вашим отделом разработки, прежде чем принимать решения.
Системы контроля версий , в том числе широко известные SVN (Subversion) и Git, изначально создавались, чтобы команды разработчиков могли работать над совместными проектами, не создавая путаницы. В системе контроля не надо самостоятельно отслеживать ветви кода и изучать примечания к ним. Вместо этого используется центральный репозиторий, где всё упорядочено, структурировано. Здесь удобно обновлять файлы, добавлять комментарии и даже проводить слияние веток проекта.
Мнения в отношении того, какая система контроля версий самая лучшая, сильно разнятся, и это приводит к бурным спорам в среде программистов. Подбирая и изучая системы контроля версий для вашего проекта, не забывайте, что преимущества того или иного решения часто субъективны. Например, личные предпочтения программиста или, скажем, такие показатели как быстродействие, возможности плагинов IDE и т.д.
Главное отличие между системами контроля версий состоит в том, какие они: клиент-серверные или децентрализованные (p2p). Есть ли у них центральный репозиторий (сервер), откуда код берется и куда возвращается с внесенными изменениями. Или это копия в локальном хранилище, обновляемая посредством пиров: более децентрализованная сеть, используемая для синхронизации, обмена патчами (наборами изменений) и для поддержки текущего кода.
Стоит также учесть быстродействие, функциональность и порог вхождения/освоения конкретной системы контроля . Рассмотрим наиболее распространенные системы контроля версий и те причины, по которым программисты предпочитают те или иные решения.
Система одновременных версий (CVS)
CVS появилась в 1980-х и до сих пор популярна как у разработчиков коммерческих продуктов, так и у open-source разработчиков.
CVS распространяется на условиях Открытого лицензионного соглашения GNU и позволяет получать с сервера нужную версию проекта — « check-out» (извлечение) , а затем пересылать обратно на сервер, « check-in» (возврат), с внесенными изменениями.
Изначально CVS была создана, чтобы избежать конфликта версий. Всем участникам для работы предоставлялась только самая последняя версия кода. Это была первая система контроля версий. Пользователю нужно было быстро фиксировать изменения в репозитории, пока другие не опередили его.
Сейчас CVS имеет поддержку работы над проектами с ветками кода. Получается несколько вариантов продукта с разными характеристиками, которые можно будет объединить позднее.
Сервера CVS обычно работают под управлением Unix, но CVS -клиенты доступны и в других популярных операционных системах. CVS — «зрелая», проверенная временем система контроля версий . Это по-прежнему опенсорсная система, но на сегодняшний день новые функции добавляются довольно редко.
При этом CVSNT, — выделившаяся в отдельный проект версия CVS для серверов Windows, — сейчас достаточно активно расширяет функционал.
Преимущества:
- Испытанная временем технология, которая удерживается на рынке десятки лет.
Недостатки:
- Переименование или перемещение файлов не отражается в истории
- Риски безопасности, связанные с символическими ссылками на файлы
- Нет поддержки атомарных операций, что может привести к повреждению кода
- Операции с ветками программного кода дорогостоящие, так как эта система контроля не предназначена для долгосрочных проектов с ветками кода
Apache Subversion (SVN)
Как и CVS , SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.
Для сохранения целостности базы данных SVN использует так называемые атомарные операции. При появлении новой версии к финальному продукту применяются либо все исправления, либо ни одно из них. Таким образом, код защищают от хаотичных частичных правок, которые не согласуются между собой и вызывают ошибки.
Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.
В то время как в CVS операции с ветками кода дорогостоящие и не предусмотрены архитектурой системы, SVN создана как раз для этого. То есть, для более крупных проектов с ветвлением кода и многими направлениями разработки.
В качестве недостатков SVN упоминаются сравнительно низкая скорость и нехватка распределенного управления версиями. Распределенный контроль версий использует пиринговую модель, а не централизованный сервер для хранения обновлений программного кода. И хотя пиринговая модель работает лучше в open source проектах, она не идеальна в других случаях. Недостаток серверного подхода в том, что когда сервер падает, то у клиентов нет доступа к коду.
Преимущества:
- Система на основе CVS
- Допускает атомарные операции
- Операции с ветвлением кода менее затратны
- Широкий выбор плагинов IDE
- Не использует пиринговую модель
Недостатки:
- Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
- Неудовлетворительный набор команд для работы с репозиторием
- Сравнительно небольшая скорость
Эта система была создана для управления разработкой ядра Linux и использует подход, который в корне отличается от CVS и SVN.
В основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий , в противовес правилам и решениям, использованным в CVS . Так как Git разрабатывалась главным образом под Linux, то именно в этой ОС она работает быстрее всего.
Git также работает на Unix-подобных системах (как MacOS), а для работы на платформе Windows используется пакет mSysGit.
Программный код может быть недоступен, когда используется компьютер без репозитория. Для решения этой проблемы есть обходные пути и некоторые разработчики полагают, что быстродействие Git является справедливой платой за неудобства.
Кроме того, в Git есть множество инструментов для навигации по истории изменений. Каждая рабочая копия исходного кода содержит всю историю разработки, что крайне полезно, когда программируешь без Интернет-соединения.
Преимущества:
- Прекрасно подходит для тех, кто ненавидит CVS /SVN
- Значительное увеличение быстродействия
- Дешевые операции с ветками кода
- Полная история разработки доступная оффлайн
- Распределенная, пиринговая модель
Недостатки:
- Высокий порог вхождения (обучения) для тех, кто ранее использовал SVN
- Ограниченная поддержка Windows (по сравнению с Linux)
Mercurial
Mercurial была выпущена одновременно с Git. Это также распределенная система контроля версий .
Система контроля версий Mercurial отличается от других систем контроля версий тем, что главным образом она написана на Python (а не С). Однако, некоторые части выполнены в качестве модулей-расширений на C.
Поскольку система децентрализованная и написана на Python, многие Python-программисты склоняются к переходу на Mercurial.
Пользователи отмечают, что Mercurial сохранила некоторые характеристики SVN, являясь при этом распределенной системой, и благодаря этой схожести, порог вхождения у нее ниже для тех, кто уже знаком с SVN. Также документация по Mercurial более полная, что помогает быстрее освоиться с различиями.
Один из существенных недостатков Mercurial заключается в том, что в отличии от Git в ней нельзя объединить две родительские ветки, так как Mercurial использует систему плагинов, а не поддержку скриптов. Это отлично подходит для некоторых программистов, но многие не хотят отказываться от возможностей Git.
Преимущества:
- По сравнению с Git легче в освоении
- Подробная документация
- Распределенная модель системы контроля версий
Недостатки:
- Нет возможности слияния двух родительских веток
- Использование плагинов, а не скриптов
- Меньше возможностей для нестандартных решений
Какая система контроля версий мне подходит?
В большинстве случаев разработчики используют CVS потому что это им привычнее. Если команда уже работает над проектом, то перспектива переноса всех наработок в другую систему контроля как-то не вдохновляет. Если бы им все-таки пришлось менять систему, то, скорее всего, они переключились бы на SVN.
CVS уже достигла статуса “зрелой технологии”, а это значит, что в ней уже не появится радикально новых функций и решений. Инерция привычки теряется, так как люди переходят на SVN. А значит CVS постепенно уходит в прошлое.
Сегодня SVN удерживает пальму первенства среди серверных систем контроля версий . Она включает в себя преимущества CVS и превосходит их. Если же говорить о распространенности, то вы, скорее всего, будете чаще сталкиваться с CVS или SVN, чем с Git или Mercurial. Таким образом, знание одной серверной технологии, хотя и не является необходимым, облегчит вам переход.
Благодаря широкому использованию и зрелости технологии, в SVN накоплена большая база знаний, что дает пользователям возможность легко получать помощь.
У Git явно выше быстродействие по сравнению с конкурентами. Для проектов, которые создаются под распределенные системы контроля версий , это очевидное улучшение.
Существенным недостатком Git является то, что порой трудно объяснить нюансы работы данной системы контроля , и это тормозит рабочий процесс, пока программисты привыкают к ней. Однако, как только «порог вхождения» преодолен, продуктивность возрастает и удобство управления ветками кода сполна окупит потраченное время.
Для тех, кто терпеть не может Git (а у этой системы есть свои противники в среде разработчиков), Mercurial — это компромисс между SVN и Git. Эта система используется во многих известных проектах, а также у нее хорошая документация.
Совместимая с Windows версия Git также прогрессирует, приближаясь по своему быстродействию к Linux-версии, так что эта система может быть для вас актуальна, даже если вы не ведете разработку в Linux.
Чтобы понять, какая же лучше для вас, учитывайте особенности проекта и вашей команды. Поговорите с разработчиками!
Если для проекта требуется единое дерево исходного кода, над которым будет работать небольшая группа программистов, то SVN – это ваш вариант. Она надежна и предназначена как раз для таких случаев.
Если же вы запускаете open-source проект, над которым в разное время будут трудиться несколько программистов или, если предполагается постоянное обновление кода, то выбирайте Git. Скорость и управление деревом исходного кода здесь намного лучше, чем в SVN.
Если вы на распутье или вам просто не нравится, как работают SVN или Git, тогда к вашим услугам Mercurial.
Все эти системы полностью функциональны. А также бесплатны. Они используются для создания программного обеспечения, сайтов и даже операционных систем, которыми вы пользуетесь, и которые вам известны.
Прежде всего, решите, подходит ли та или иная система контроля версий для вашего бизнеса, а затем — что не менее важно — убедитесь, что этот выбор не приведет в ярость программистов.
Приступая к работе с SVN
Если вы никогда не работали с SVN или Git, и понятия не имеете, как начать, то хостинговое решение в сочетании с графическим интерфейсом помогут вам быстро освоиться.
Как и в большинстве случаев, самое главное — начать работу, а там уже придет понимание. Эксплуатация системы контроля версий очень похожа на работу с файлами на сервере с использованием FTP-клиента.
ПРИМЕЧАНИЕ: Есть множество хостинговых решений для системы контроля версий , в том числе с бесплатным пробным периодом. Вы можете создать на их базе свой первый репозиторий (место для совместной работы с файлами кода) совершенно бесплатно. Вот некоторые из этих сервисов:
Хостинг SVN & GIT
— безопасный, надежный и подходящий для хостинга Git и Subversion. Просмотр активности, файлов, сравнение ревизий. Отличный пользовательский интерфейс. Интеграция со многими популярными сервисами, включая Twitter! Цена вопроса: от $15 в месяц
– популярный среди разработчиков ПО хостинг для SVN, Git и управления проектами с хостинговым решением. С помощью виджета для Mac OS с простым и понятным интерфейсом вы можете следить за активностью в аккаунте во всех ваших проектах. 2 пользователя бесплатно + 1 проект с хранилищем до 200MB
– еще одна опция для бесплатного хостинга, но не такая хорошая как Unfuddle. 1 пользователь бесплатно + 1 проект с хранилищем до 100MB
– хостинг Subversion, Git и Mercurial. Отличное соотношение цены и функционала. От $5 в месяц, неограниченное число проектов, пользователей и хранилище до 2GB
Создание первого репозитория
После того как вы создали аккаунт, необходимо создать репозиторий — для каждой платформы отдельно. Обычно это выглядит так:
- Войдите в свой аккаунт, кликните по вашим проектам.
- Создание проекта:
- В строке «Create a New Project» введите имя вашего проекта
- Кликните по кнопке «Create Project»
- Подключение SVN:
- После создания проекта, выберите вкладку «Source Control» (версиями исходного кода)
- Кликните по ссылке «Enable Source Control»
- Присвойте репозиторию имя
- Нажмите «Save»
Графические клиенты SVN и GIT
Итак, репозиторий создан. Теперь нужно, чтобы в нем все отображалось просто и наглядно. Для этого вам понадобится графический интерфейс.
— удобная программа для работы с системами контроля версий в Microsoft Windows и, возможно, лучший из представленных Apache Subversion клиент. TortoiseSVN реализован как расширение оболочки Windows, что позволяет легко интегрировать его в браузер. Кроме того, это программа с открытым исходным кодом, для которой доступны 34 языковых пакета
– графический клиент Git (Open Source распределенная система контроля версий ). Работает в Windows, Mac OS X и Linux. Стоимость лицензии — $39
– SVN клиент для MAC OS X – Versions: простейшая с истема контроля версий для Mac. По их собственным словам: «Благодаря нашему подходу, вы сможете начать без раскачки». Данный клиент прост в использовании. Цена вопроса: £39 (примерно $50 согласно текущему курсу)
– Клиент GIT для MAC OS X – еще одно элегантное решение, идеально подходящее для пользователей GIT, которые уже знакомы с синтаксисом командной строки. Есть также хороший ознакомительный обзор продукта, содержащий множество базовых концепций GIT (см. ниже). ~ примерно $50 за лицензию, доступны менее затратные мульти-лицензионные опции.
«Извлечение» репозитория (“Checkout”)
Итак, клиент выбран. Теперь необходимо создать репозиторий для системы контроля. Нужно ввести URL-адрес вашего репозитория, имя пользователя и пароль.
- Перейдите в корневую папку, нажмите кнопку «Check Out» («Извлечение») и создайте рабочую папку для клиента. Теперь вы можете добавлять в нее файлы.
- После извлечения файлов проекта вы сможете редактировать их в локальной директории на вашем компьютере.
После внесения изменений в файлы для их сохранения нажмите кнопку «Check-in» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии — это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.
В вашем клиенте также должна быть предусмотрена возможность в любой момент начать работу с ревизиями, открыв журнал ревизий или историю изменений — тогда, если понадобится, вы сможете сделать «откат» к предыдущей версии для каждого файла в отдельности. Теперь, когда вы знакомы с базовыми концепциями, документация системы контроля версий послужит вам хорошей отправной точкой для освоения ее расширенных функциональных возможностей.
Читайте также: