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

Система контроля версий (cvs), 2017 — Сравниваем: Git, SVN, Mercurial

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

Если вы еще не знакомы с концепцией системы контроля версий , то вот все очень наглядно показано.

Или посмотрите видео от 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)

SVN создавалась как альтернатива CVS с целью исправить недостатки CVS и в то же время обеспечить высокую совместимость с ней.

Как и CVS , SVN это бесплатная система контроля версий с открытым исходным кодом. С той лишь разницей, что распространяется под лицензией Apache, а не под Открытым лицензионным соглашением GNU.

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

Многие разработчики переключились на SVN, так как новая технология унаследовала лучшие возможности CVS и в то же время расширила их.

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

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

Преимущества:

• Система на основе CVS
• Допускает атомарные операции
• Операции с ветвлением кода менее затратны
• Широкий выбор плагинов IDE
• Не использует пиринговую модель

Недостатки:

• Все еще сохраняются ошибки, связанные с переименованием файлов и директорий
• Неудовлетворительный набор команд для работы с репозиторием
• Сравнительно небольшая скорость

Git

Эта система была создана для управления разработкой ядра Linux и использует подход, который в корне отличается от CVS и SVN.

В основу Git закладывались концепции, призванные создать более быструю распределенную систему контроля версий , в противовес правилам и решениям, использованным в CVS . Так как Git разрабатывалась главным образом под Linux, то именно в этой ОС она работает быстрее всего.

Git также работает на Unix-подобных системах (как MacOS), а для работы на платформе Windows используется пакет mSysGit.

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

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

Преимущества:

• Прекрасно подходит для тех, кто ненавидит CVS /SVN
• Значительное увеличение быстродействия
• Дешевые операции с ветками кода
• Полная история разработки доступная оффлайн
• Распределенная, пиринговая модель

Недостатки:

• Высокий порог вхождения (обучения) для тех, кто ранее использовал SVN
• Ограниченная поддержка Windows (по сравнению с Linux)

Mercurial

Mercurial была выпущена одновременно с Git. Это также распределенная система контроля версий .

Mercurial создавалась в качестве альтернативы Git для разработки модулей ядра Linux. Но так как выбрали все-таки Git, то Mercurial используется меньше. Тем не менее, многие ведущие разработчики работают именно с этой системой, например OpenOffice.org .

Система контроля версий 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

Создание первого репозитория

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

• Войдите в свой аккаунт, кликните по вашим проектам.
• Создание проекта:

• В строке «Create a New Project» введите имя вашего проекта
• Кликните по кнопке «Create Project»

• Подключение SVN:

• После создания проекта, выберите вкладку «Source Control» (версиями исходного кода)
• Кликните по ссылке «Enable Source Control»
• Присвойте репозиторию имя
• Нажмите «Save»

Графические клиенты SVN и GIT

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

— удобная программа для работы с системами контроля версий в Microsoft Windows и, возможно, лучший из представленных Apache Subversion клиент. TortoiseSVN реализован как расширение оболочки Windows, что позволяет легко интегрировать его в браузер. Кроме того, это программа с открытым исходным кодом, для которой доступны 34 языковых пакета

SmartGit

– графический клиент Git (Open Source распределенная система контроля версий ). Работает в Windows, Mac OS X и Linux. Стоимость лицензии - $39

«Извлечение» репозитория (“Checkout”)

Итак, клиент выбран. Теперь необходимо создать репозиторий для системы контроля. Нужно ввести URL-адрес вашего репозитория, имя пользователя и пароль.

URL-адрес обычно выглядит так: https://svn.hostname.com/svn/ > (вы можете использовать https:// (SSL), если у вас платный аккаунт)

1. Перейдите в корневую папку, нажмите кнопку «Check Out» («Извлечение») и создайте рабочую папку для клиента. Теперь вы можете добавлять в нее файлы.
2. После извлечения файлов проекта вы сможете редактировать их в локальной директории на вашем компьютере.

После внесения изменений в файлы для их сохранения нажмите кнопку «Check-in» («Возврат») на панели инструментов. Вы можете просматривать изменения и добавлять к ним комментарии - это довольно хорошая идея, так как в дальнейшем вы будете точно знать, над чем работали, какие изменения внесены и будете держать в курсе других участников проекта.

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

RCS (Revision Control System, Система контроля ревизий) была разработана в начале 1980-х годов Вальтером Тичи (Walter F. Tichy). Система позволяет хранить версии только одного файла, таким образом управлять несколькими файлами приходится вручную. Для каждого файла находящегося под контролем системы информация о версиях хранится в специальном файле с именем оригинального файла к которому в конце добавлены символы ",v" . Например для файла file.txt версии будут храниться в файле file.txt,v . Для хранения версий система использует утилиту diff , то есть хранятся только изменения между версиями.

Рассмотрим пример сессии с RCS (знак $ здесь и далее обозначает приглашение операционной системы). Когда мы хотим положить файл под контроль RCS мы используем команду ci (от check-in, регистрировать):

$ ci file.txt

Данная команда создает файл file.txt,v и удаляет исходный файл file.txt (если не сказано этого не делать). Также эта команда запрашивает описание для всех хранимых версий. Так как исходный файл был удален системой мы должны запросить его обратно, что бы вносить изменения. Для этого мы используем команду co (от check-out, контролировать):

$ co file.txt

Эта команда вынимает последнюю версию нашего файла из file.txt,v . Теперь мы можем отредактировать файл file.txt и после того как закончим изменения опять выполнить команду ci для того что бы сохранить новую измененную версию файла:

$ ci file.txt

При выполнении этой команды система запросит у нас описание изменений и затем сохранит новую версию файла.

Хотя RCS соответствует минимальным требованиям к системе контроля версий она имеет следующие основные недостатки, которые также послужили стимулом для создания следующей рассматриваемой системы:

• Работа только с одним файлом, каждый файл должен контролироваться отдельно;
• Неудобный механизм одновременной работы нескольких пользователей с системой, хранилище просто блокируется пока заблокировавший его пользователь не разблокирует его;

CVS

CVS (Concurrent Versions System, Система совместных версий) пока остается самой широко используемой системой, но быстро теряет свою популярность из-за недостатков которые я рассмотрю ниже. Дик Грун (Dick Grune) разработал CVS в середине 1980-х. Для хранения индивидуальных файлов CVS (также как и RCS) использует файлы в RCS формате, но позволяет управлять группами файлов расположенных в директориях. Также CVS использует клиент-сервер архитектуру в которой вся информация о версиях хранится на сервере. Использование клиент-сервер архитектуры позволяет использовать CVS даже географически распределенным командами пользователей где каждый пользователь имеет свой рабочий директорий с копией проекта.

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

CVS также позволяет вести несколько линий разработки проекта с помощью ветвей (branches) разработки. Таким образом, как уже упоминалось выше, можно исправлять ошибки в первой версии проекта и параллельно разрабатывать новую функциональность.

Рассмотрим небольшой пример сессии с CVS. Прежде всего надо импортировать проект в CVS, это делается с помощью команды import (импортировать):

$ cd some-project $ cvs import -m "New project" path-in-repository none start

Здесь опция -m позволяет задать описание изменений прямо в командной строке и если ее опустить, то будет вызван текстовый редактор. Далее указывается путь по которому проект будет храниться в репозитории (path-in-repository в нашем случае) и после него две метки: метка разработчика (может пригодится в случае использования CVS для работы над проектами разработанными кем-то другим) и метка проекта.

После того как мы залили наш проект в репозиторий необходимо создать новый директорий в котором будет находится рабочая копия проекта под контролем CVS и загрузить проект с помощью команды checkout (контроль), или сокращенно co :

$ cd some-working-dir $ cvs checkout path-in-repository

Для команды checkout мы указываем путь к нашему проекту в репозитории который мы указывали выше в команде import .

Теперь мы можем внести в проект изменения и залить их в репозиторий с помощью команды commit (совершить изменения), или сокращенно ci :

$ cvs commit -m "Some changes"

Также как и для команды import мы указываем комментарий к нашим изменениям с помощью опции -m .

Если мы хотим обновить наш рабочий директорий новой версией проекта из репозитория мы используем команду update (обновить), или сокращенно up :

$ cvs update

CVS использовалась большим количеством проектов, но конечно не была лишена недостатков которые позднее привели к появлению следующей рассматриваемой системы. Рассмотрим основные недостатки:

• Так как версии хранятся в файлах RCS нет возможности сохранять версии директорий. Стандартный способ обойти это препятствие - это сохранить какой-либо файл (например, README.txt) в директории;
• Перемещение, или переименование файлов не подвержено контролю версий. Стандартный способ сделать это: сначала скопировать файл, удалить старый с помощью команды cvs remove и затем добавить с его новым именем с помощью команды cvs add ;

Subversion

Subversion (SVN) был разработан в 2000 году по инициативе фирмы CollabNet . SVN изначально разрабатывался как "лучший CVS" и основной задачей разработчиков было исправление ошибок допущенных в дизайне CVS при сохранении похожего интерфейса. SVN также как и CVS использует клиент-сервер архитектуру. Из наиболее значительных изменений по сравнению с CVS можно отметить:

• Атомарное внесение изменений (commit). В случае если обработка коммита была прервана не будет внесено никаких изменений.
• Переименование, копирование и перемещение файлов сохраняет всю историю изменений.
• Директории, символические ссылки и мета-данные подвержены контролю версий.
• Эффективное хранение изменений для бинарных файлов.

Рассмотрим примеры команд, хотя надо заметить, что большинство из них практически повторяют команды CVS. Что бы использовать проект с SVN его надо сначала импортировать в репозиторий с помощью команды import (импортировать):

$ cd some-project $ svn import -m "New project" path-in-repository

В отличие от CVS не нужно указывать метки разработчика и проекта, которые не часто использовались на практике.

Теперь нам нужно создать рабочую копию проекта с помощью команды checkout (контроль), или co :

$ cd some-working-dir $ svn checkout path-in-repository

После внесения изменений мы используем команду commit (совершить изменения) , или ci для сохранения изменений в репозитории:

$ svn commit -m "Some changes"

И для обновления рабочей копии проекта используется команда update (обновить), или up .

Вопрос был бы уместен лет 25 назад. Уже лет 10 использование системы контроля версий - это обязательная вещь для любой команды. Общее, удобное, безопасное хранение исходных кодов с историей изменений, коллективное владение кодом, разделение задач и функционала приложения внутри команды. А также автоматизация сборок, развертывания и вообще непрерывная интеграция.

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

Александр Макарчук , qb
Оптимизация командной разработки.

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

2. Какие факторы влияют на выбор системы контроля версий?

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

Иван Немытченко , GitLab
Популярность той или иной системы, из которой следует уже все остальное: поддержка в приложениях и сервисах, количество и качество документации, наличие эксперта «под боком» и т.п.

Александр Макарчук , qb
В нашем случае выбор основывается на популярности системы контроля версий и уровне владения ей разработчиками.

Петр Урваев , SimbirSoft
В первую очередь - соответствие возможностей системы контроля версий принятому в команде процессу разработки. Во вторую очередь, то с какой системой контроля версий привычнее работать участникам проекта.

3. Как внедрить использование системы контроля версий в команде?

Николай Фетюхин , MST
Сейчас даже современные студенты уже выпускаются с общим пониманием, для чего необходимы системы контроля версий, поэтому вопрос внедрения не совсем корректен. Обычно все проекты просто по умолчанию начинаются с создания репозитория. Если же в общем случае, то следует поговорить с командой, выяснить почему системы контроля версий на проекте нет (изредка бывают различные крайне специфические случаи), и если проблемы преодолимы, то провести пару семинаров внутри команды по конкретной системе контроля версий (если требуется) и запускаться.

Иван Немытченко , GitLab
Дать им возможность поработать без системы контроля версий, чтобы прочувствовали всю боль. Потом «подсунуть» им cheatsheet по Git-у, и они сами все выучат и внедрят. Но так можно работать со школьниками и студентами. У зрелых разработчиков обычно этот вопрос не стоит.

Александр Макарчук , qb
Медленно, но верно каждый приходит к этому самостоятельно.

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

4. Благодаря чему Git стал стандартом в мире систем контроля версий? Сможет ли его кто-то сместить с лидирующего положения?

Николай Фетюхин , MST
Git изначально содержал несколько полезных вещей, таких как локальные коммиты, а также решил большое количество проблем со слиянием веток, которыми был богат предыдущий законодатель мод - Subversion (SVN). С самого начала он боролся за популярность с Mercurial (Hg), который в некоторых аспектах проще, но в итоге вырвался в лидеры.

Иван Немытченко , GitLab
Благодаря тому, что Линус Торвальдс атаковал проблему распределенной разработки с правильной стороны, учтя недостатки систем-предшественников. Сместить? А зачем?

Александр Макарчук , qb
Благодаря тому, что Git - молодец. Очень долго никто его не сместит.

Петр Урваев , SimbirSoft
Основное преимущество Git - развитость инструментов для работы с ним и возможность хранения в нем результатов работы по нескольким параллельно открытым задачам так, что промежуточные результаты не влияют друг на друга, и при этом окончательные результаты можно достаточно легко скомбинировать в одну итоговую версию приложения. Также немаловажную роль во всеобщей популярности Git’a в мире CVS сыграл ресурс GitHub, на котором размещены тысячи репозиториев на различных языках.

5. Что не устраивает разработчиков в Git? Почему некоторые выбирают другие менее популярные решения?

Николай Фетюхин , MST
Единственный значимый для нас недостаток Git - это некоторые проблемы с отслеживанием изменений: ветки могут быть удалены, и может остаться только merge-коммит. Это связано во многом с тем, что у Git ветки привязаны к коммитам. Также у Git более крутая кривая обучения, чем у упомянутого выше Mercurial или Subversion.

Александр Макарчук , qb
В рамках наших задач всем устраивает.

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

6. Насколько распространено использование систем контроля версий для управления другими файлами, а не только кодом?

Николай Фетюхин , MST
В настоящее время повсеместно. Те же облачные системы вроде One Drive, Яндекс.Диск, Dropbox и Google Drive в основе содержат идеологию, повторяющую системы контроля версий.

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

Александр Макарчук , qb
Постоянно используется.

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

Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы Git, SVN, CVS и знаете много других умных слов. Позвольте же и нам, простым смертным, ознакомиться со всеми преимуществами использования СКВ.
Приглашаю под кат всех желающих ознакомиться с СКВ, а также всех тех, кто, так или иначе, имеет дело с быстроменяющимися данными.

Зачем это нужно

Сам я являюсь студентом технического ВУЗа и практически постоянно работаю с документами (текстами, рисунками, чертежами), изменяя их по три (десять, сто) раз на дню. Порой получается так, что правки, сделанные в течение последней недели, необходимо отменить и вернуться к документам в состоянии недельной давности. Хорошо, если правок было сделано немного, в этом случае могут помочь полсотни ударов по Ctrl+Z. Однако если в течение этой недели шла более-менее активная работа с документом, просто так восстановить статус «до важной правки, сделанной неделю назад» не получится. Для этого необходима копия документа на момент «до важной правки», а также еще десяток копий «до другой важной правки», «до сомнительной правки» и «до правки, которую, скорее всего, придется отменить». В принципе, такой подход возможен и практикуется многими. До недавнего времени я и сам держал важные версии файлов, сохраняя их с префиксами «дата_время», и, вроде бы, был доволен. Преимуществом этого метода является простота, недостатком – «разбухание» рабочих папок и неудобство использования. И, если с первым из них можно как-то бороться (большими жесткими дисками и 7zip’ом), то с неудобством что-то нужно было делать.

Что с этим можно сделать, или что такое СКВ

Вырываем абзац из Википедии: «Система управления версиями (от англ. Version Control System, VCS или Revision Control System) – программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости, возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение и многое другое». Похоже на принцип работы самой Википедии – все версии статей со всеми правками доступны для изучения.
Таким образом, использование СКВ в ситуации, когда нужно хранить множество версий файлов – то, что надо. К преимуществам такого подхода относятся удобство использования и экономия свободного дискового пространства благодаря так называемому дельта-сжатию (когда сохраняются не сами файлы в различных версиях, а изменения от версии к версии, что уменьшает объем хранимых данных). Давайте попробуем.

Какие бывают СКВ

Та же Википедия подсказывает, что СКВ бывают централизованные и распределенные, большие и маленькие, с примочками и без. Нас это не особо интересует, так как мы будем пользоваться (по крайней мере, сначала) только частью функционала СКВ. Этот самый функционал и рассмотрим.
Практически все СКВ представляют собой некое хранилище, в котором хранятся все версии файлов, с которыми мы работаем. Здесь необходимо уточнить, что версии хранимых файлов чаще всего определяет пользователь. Внесли мы, допустим, с десяток мелких правок и решили, что пора бы сохранить результаты нашей деятельности в хранилище. В голову приходит аналогия с периодическим нажатием Ctrl+S, с тем лишь отличием, что к данной версии файла можно будет обращаться в будущем. Естественно, что «одним махом» таким образом можно занести в хранилище версии сколь угодно большого количества файлов. Называется это действие «commit», или «фиксация изменений» по-простому.
В любой момент в репозиторий (а именно так по-умному называется хранилище) можно добавить новый или удалить существующий файл, и СКВ будет «помнить» когда и что мы добавили/удалили. А благодаря комментариям при commit’ах можно еще и описать для чего собственно данный commit выполняется («добавили фенечку туда-то»/«удалили возможно нужный кусок оттуда-то»).
Когда же мы, наконец, понимаем, что пора бы нам вернуться к версии недельной давности, у нас имеется вся история изменений. И тут мы можем выбирать, как поступить. Если необходимо скопировать из старого файла нужный кусочек и вставить в текущую версию – просто извлекаем из хранилища старый файл и копируем из него необходимое. Если же необходимо полностью откатиться назад и продолжить работу со старой версией нам на помощь снова приходит СКВ – можно вернуться к ранней версии и создать так называемую новую ветку («branch»), сохранив при этом все, от чего мы «отказались», откатившись в версиях на неделю назад. Таким образом, историю версий проекта графически можно представить в виде дерева – от «корней» (начала проекта) до «ветвей» (удачных и неудачных правок). Кроме того, «ветку» можно создать и искусственно, к примеру, в том случае, когда из одних исходных файлов мы решим развить две различные версии – в первой работаем над одними фенечками, во второй – над другими. Более того, в случае, если рабочие файлы представляют собой текстовые документы (и в некоторых других), возможно объединение различных веток в одну – так называемое слияние («merge»). Теперь представим, что над проектом работают несколько человек, и каждый занимается своей такой «фенечкой». Наличие общего репозитория в этом случае сильно упрощает разработку.

От теории к практике, или начинаем использовать СКВ

Итак, надеюсь, я убедил вас в том, что использование СКВ – это хорошо. Осталось лишь научиться использовать СКВ. Этим и займемся.
Существуют различные системы контроля версий, отличающиеся друг от друга различными аспектами использования. Так как нас не интересуют (по крайней мере, сначала) тонкости работы различных систем, остановимся на самой простой и дружелюбной из них. По моему скромному мнению, такой системой, как ни странно, является Mercurial – «кроссплатформенная распределённая система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода» с графической оболочкой TortoiseHg. Работа с системой возможна под Windows, Linux и Mac OS X.
Сразу оговорюсь, что буду описывать работу с системой в Windows. Освоившим Linux не составит труда изучить все по аналогии.
Кроме того, параллельно обучимся работать с бесплатным хостингом Mercurial репозиториев – bitbucket.org, необходимым в случае, если вы работаете над проектом не одни или же, что очень удобно, хотите иметь доступ ко всем версиям проекта через интернет. По сути, это удобная замена Dropbox, если вы использовали его ранее.
Для начала устанавливаем Mercurial + TortoiseHg отсюда: tortoisehg.bitbucket.org.
Эта система работает в консоли, поэтому для удобства использования позже напишем несколько *.bat файлов для типичных операций.
Все операции производятся командой hg. Вызванная без параметров, она выводит список основных команд.
В качестве репозитория выступает любая выбранная нами директория (я буду использовать папку “C:\project\”), в которой и должны храниться все файлы нашего будущего проекта. Разумеется, никто не запрещает иметь несколько репозиториев на одном компьютере.
Чтобы система «поняла», что мы хотим создать репозиторий, выполняем команду:
hg init c:\project
после которой будет создана папка “c:\project\”, если она не была создана ранее и папка “c:\project\.hg\”, в которой Mercurial будет хранить всю служебную информацию.
Тут же вспоминаем, что хотим получить не только локальный репозиторий на своем компьютере, но и удаленный репозиторий, в который будем отправлять все наши изменения (или, как говорят умники, «пушить» изменения в удаленный репозиторий, от англ. «push»). Для этого идем на bitbucket.org, регистрируемся, и создаем свой первый репозиторий (Repositories - Create new repository). Даем репозиторию имя (я для определенности назову его remote_project) и жмем на Create repository.
Теперь у нас имеются два репозитория – локальный, находящийся в папке “c:\project\” и удаленный, расположенный по адресу “bitbucket.org/имя_вашей_учетки/remote_project/”, где имя_вашей_учетки – указанное при регистрации на bitbucket, remote_project – имя репозитория, выбранное при его создании.
Для того, чтобы продолжить изучение, нам необходимо поместить что-нибудь в наш локальный репозиторий. Просто создайте в нем (в моем случае – в папке “c:\project\”) любой файл вашего будущего проекта либо скопируйте туда ваш текущий проект.
Теперь, строго говоря, нам необходимо указать Mercurial: «мы добавили в папку проекта такой-то и такой-то файлы и пару новых папок», для этого предусмотрена команда “hg add”. Однако, более удобен другой подход – при очередном commit’е мы прикажем Mercurial подхватить все свежесозданные файлы из папки проекта и забыть про удаленные, это гораздо легче, чем каждый раз при создании нового документа выполнять “hg add c:\project\new_document.doc”.
Итак, приступаем к нашему первому commit’у. Выполняется он следующей командой:
hg commit –A –m “comment to commit”
Разберем все по порядку. Команда должна вводиться тогда, когда мы находимся в репозитории (то есть предварительно необходимо выполнить “cd c:\project”). Опция “-A” необходима для того, чтобы Mercurial «подхватил» свежесозданные файлы (см. выше), опция “-m” позволяет добавить к commit’у комментарий. Эти комментарии будут отображаться при просмотре версий (или changeset’ов – списков изменений) в TortoiseHg и на странице проекта в bitbucket.org. Очень важно давать осмысленные комментарии, чтобы потом не мучаться, вспоминая, когда же была сделана та или иная правка.
Теперь в нашем репозитории хранится начальная версия нашего проекта. Все дальнейшие commit’ы выполняются аналогично после того, как мы решим, что пора бы сохранить текущую версию.
Сделанный commit можно «втолкнуть» в удаленный репозиторий командой:
hg push https://bitbucket.org/имя_вашей_учетки/remote_project
При этом также необходимо находиться в папке, соответствующей репозиторию. После ввода команды будет запрошено имя и пароль нашей учетки на bitbucket.org, чтобы не вводить их при каждом push’е команду можно заменить на следующую:
hg push hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Так как все команды мы забьем в *.bat файл, в этом случае пароль будет храниться в открытом виде, что представляет собой некоторую угрозу безопасности, однако для меня это приемлемо.
Итак, для удобства создаем в зоне прямой досягаемости файлы commit.bat, push.bat и commit&push.bat со следующим содержанием:
[содержание файла commit.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
Этот файл, вызванный с аргументами, выполнит commit проекта с занесением аргументов в комментарии к commit’у. Пример: выполняем “commit.bat my first commit” и получаем commit с комментарием «my first commit». В FAR’е для этого удобно использовать сочетание Ctrl+Enter.
[содержание файла push.bat]
cd C:\project
hg push https://имя_вашей_учетки:пароль_вашей_учетки@bitbucket.org/имя_вашей_учетки/remote_project
Этот файл произведет push в удаленный репозиторий.
[содержание файла commit&push.bat]
IF !%1==! goto exit1
cd C:\project
hg commit -A -m "%*"
goto exit0
:exit1
echo "NO COMMAND-LINE ARG!"
:exit0
call ./push.bat
Этот файл, вызванный с аргументами, выполнит последовательный commit и push проекта с занесением аргументов в комментарии к commit’у.
Кроме того, для мелких промежуточных commit’ов я рекомендую создать файл commit_date_time.bat:
[содержание файла commit_date_time.bat]
cd C:\project
hg commit -A -m "%DATE% %TIME%"
Этот файл произведет commit с указанием текущей даты и времени в качестве комментария, что часто бывает удобно.
Вопрос о частоте commit’ов и push’ей каждый решает в индивидуальном порядке в зависимости от интенсивности и сложности вносимых правок. Хотя и рекомендуется руководствоваться правилом «чаще – лучше».
Правым кликом на файле/папке репозитория можно запустить Repository Explorer (TortoiseHg - Repository Explorer), в котором представлены все наши commit’ы с комментариями к ним. В этом окне отображается древовидная структура нашего репозитория, отсюда же можно производить commit’ы, push’и, откаты к предыдущим версиям (backout’ы) и другие операции.
По адресу bitbucket.org/имя_вашей_учетки/remote_project находится аналогичный набор changeset’ов, при этом можно скачать любую версию проекта одним архивом, что иногда также очень удобно.
В общем, первоначальное знакомство с Mercurial на этом считаю оконченным. За более подробной информацией можно обратиться по адресу: translated.by/you/mercurial-the-definitive-guide/into-ru/trans/

Для кого эта статья

Закончу, пожалуй, тем, с чего следовало бы начать – для кого эта статья? Ответ прост – для тех, кто хочет научиться использовать СКВ. Мне удалось «подсадить» на СКВ нескольких дизайнеров, инженеров и даже писателя. Попробуйте и вы – этим вы, возможно, сильно облегчите себе работу.

P. S. Перенес в блог «Системы управления версиями».

Теги: Добавить метки

Миша Радионов

Что такое системы контроля версий и зачем они нужны Вам

Вернуться в

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

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

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

Что такое VCS?

Система управления версиями (от англ. Version Control System, VCS или Revision Control System) - программное обеспечение для облегчения работы с изменяющейся информацией.Wikipedia

А теперь по-простому

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

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

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

Простой пример

Если над одним Excel документом работает несколько человек, то для редактирования файл доступен только одному человеку, остальные получают доступ “только на чтение”. С использованием VCS Вы получаете возможность редактирования файла сразу и всеми. Единственным условием является только то, что после внесения изменений, файл нужно сохранить на сервер, а не на локальный компьютер. Но как было сказано выше, инструменты позволяют производить такие действия легко и просто.

Система контроля версий в студии Флаг

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

Мы используем программу для разработки программного кода, которая называется IntelliJ IDEA . Она предоставляет собой IDE, то есть большую функциональную базу для разработчиков, в том числе в нее включен удобный интерфейс по работе с контролем версий. Так, не выходя из программы, мы можем увидеть, какие изменения были произведены тем или иным разработчиком на нужном нам сайте. Или, не боясь потерять свои изменения, получить изменения, сделанные другим разработчиком. Выглядит интерфейс IDEA примерно так:

Для хранения версий мы пользуемся облачным сервисом Bitbucket . Этот сервис удобен своим интерфейсом и, помимо услуг по хранению ваших версий, позволяет управлять правилами доступа к вашим продуктам разным пользователям. Плюсом использования облачного хранилища является отсутствие каких-то требований к знанию настройки и администрирования сервера. Вы все получаете “из коробки” и сразу можете начинать пользоваться. Все, что вы загружаете в bitbucket, является приватным, т.е. без вашего разрешения никто другой не сможет даже увидеть, что вы храните. Интерфейс Bitbucket:

Что нам дает использование VCS

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

Что это дает нашим клиентам

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

Please enable JavaScript to view the