Привет, Хабр. Решил затронуть измученную во многих статьях тему, конкретнее – описать во многом нестандартное (я бы сказал, несорцовое) использование систем контроля версий (далее – СКВ). Товарищи программисты, давайте спрячем тухлые помидоры и пройдем мимо, ибо данная статья – не для вас. Да, все вы уже изучили все тонкости работы 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. Перенес в блог «Системы управления версиями».

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

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

Естественно, поиски были начаты с изучения Хабра - и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 1986 году, большинство туториалов по работе с современными системами контроля версий оказались неполными и сильно завязанными на работу с командной строкой.

Мы ничего не имеем против командной строки в целом, но в нашей небольшой команде разработчиков (4 человека) фанатов работы с командной строкой нет:).

Почему мы считаем, что работа с командной строкой неэффективна?

1. Трата времени на ввод данных. Набивать команды намного дольше, чем кликать мышкой.
2. Трата времени на обучение. Изучение нового синтаксиса в эпоху понятных интерфейсов однозначно дольше, чем обучение графическому интерфейсу.
3. Вероятность ошибки. Ошибиться при вводе данных через командную строку легче (человеческий фактор никто не отменял).
4. Нарушение принципов автоматизации . Возможно, это самый главный пункт. Компьютер создан для ускорения работы и замене человека при выполнении рутинных операций. В случае с командной строкой мы всегда работаем вручную , по сути, приходится каждый раз писать один и тот же программный код (пусть и примитивный).

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

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

Вступление

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

Если вы не любитель мануалов «Для чайников», то можете не читать данную статью и пойти своим путем в решении задачи подъема VCS.

Используемые программы и сервисы

Для развертывания VCS (системы контроля версий) мы будем использовать следующие программы и сервисы:

• Mercurial - кроссплатформенная распределенная система управления версиями, разработанная для эффективной работы с очень большими репозиториями кода.
• TortoiseHg - графический фронтенд для системы контроля версий Mercurial.
• Bitbucket - веб-сервис для хостинга проектов и их совместной разработки, основанный на системе контроля версий Mercurial и Git.

Развертывание система контроля версий – пошаговая инструкция

1. Скачиваем и устанавливаем к себе на компьютер TortoiseHg с официального сайта: http://tortoisehg.bitbucket.org/

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

В данной инструкции все шаги настройки и работы с системой контроля версий будут производиться с использованием TortoiseHg версии: 2.10.1 for Windows 64-bit with Mercurial 2.8.1.

2. Регистрируемся в веб-сервисе Bitbucket: https://bitbucket.org/
Весь процесс регистрации сводится к заполнению контактных данных (Username, Email и т.д.) и подтверждения указанного при регистрации email-адреса нажатием на кнопку «Confirm this email address» в полученном после регистрации письме.

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

С полным списком тарифов вы можете ознакомиться, пройдя по ссылке: https://bitbucket.org/plans

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

Для этого в верхнем правом углу главного меню из выпадающего списка выберите раздел «Manage account» и на открывшейся странице выберите из выпадающего списка «Language» нужный вам язык интерфейса

4. Для создание репозитория для вашего проекта вам необходимо перейдите на главную страницу вашего аккаунта (https://bitbucket.org/dashboard/overview) и нажмите на кнопку «Создайте ваш первый репозиторий»

5. На странице создания нового репозитория укажите следующие настройки:

Имя – Укажите имя вашего нового репозитория. Данное имя используется для построения ссылки доступа к вашему репозиторию.
Важно! Лучше указывать имя латинскими буквами, иначе ссылка на репозитрий будет заканчиваться дефисами и иметь сложный к пониманию вид: httрs://вашлогин@bitbucket.org/вашлогин/--------

Описание – Укажите краткое описание вашего репозитория (поле не обязательное)
- Уровень доступа – Поставьте галочку, если вы хотите, чтобы доступ к вашему репозиторию имели только члены вашей команды разработчиков (приватный репозиторий).
- Создание форков – Поставьте «Разрешить только приватные форки»
- Тип репозитория – Выберите «Mercurial»
- Управление проектом – Поставьте галочки «Трекер задач» и «Вики»
- Язык – Выберите язык разработки, на котором написан ваш проект. В моем случае это PHP.

По завершению указания всех настроек страница будет выгладить приблизительно так:

Еще раз проверьте введенные данные и если все введено корректно, жмем кнопку «Создать репозиторий».

6. После создания нового репозитория вы попадете на страницу «Начало работы»:

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

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

8. В открывшемся окне вам необходимо указать в поле «Источник» ссылку для подключения к созданному вами репозиторию из п. 6

И нажать кнопку «Клонировать».

9. Система запросит у вас пароль от вашего аккаунта в сервисе Bitbucket, укажите его.

10. Если все было сделано без отклонений от данной инструкции, то в папке появится новый каталог «.hg» со служебными файлами созданного репозитория.

11. Теперь можно смело возвращать файлы (программный код) вашего проекта в папку, предназначенную для хранения файлов проекта, подключенных к системе контроля версий Mercurial

Важно! Служебный каталог «.hg» не трогайте. Он нужен для работы VCS.

12. Снова нажимаем правой кнопкой мыши на нашей папке проекта и из выпадающего меню выбираем пункт «Hg Commit…»

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

Вам необходимо выделить все измененные (добавленные) файлы, указать комментарий (например, Версия 1.00) к изменению и нажать кнопку «Фиксировать».

Система попросит подтвердить добавление, жмите «Добавить».

14. Если все было сделано правильно, то система зафиксирует произведенные изменения, и вы увидите приблизительно такое окно:

Собственно, в дальнейшем, когда будете вести разработку, после завершения небольшого куска кода, вы будете выполнять действие из п. 12 (нажимать «Hg Commit…») для фиксации проделанного изменения в системе контроля версия. Это даст вам возможность в любой момент времени откатить систему до предыдущей фиксации.

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

16. В открывшемся окне вы можете видеть всю историю сохраненных (зафиксированных) изменений в коде, можете откатить к нужной фиксации, а также отправить изменения в созданный вами ранее репозиторий.

Для этого в панели управления выберите кнопку «Протолкнуть входящие изменения в».

После этого вам будут показаны диалоговые окна с просьбой подтвердить «проталкивание» и просьбой указать пароль от вашего аккаунта в Bitbucket. Соглашайтесь и указывайте пароль.

Система начнет копирование файлов в ваш репозиторий на сервере Bitbucket. Не спешите и дождитесь завершения процесса.

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

Промежуточные итоги подключения системы контроля версий (VCS)

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

Процесс подключения вашего второго компьютера заключается в копировании файлов из репозитория на второй компьютер. Вам нужно пройти шаги 1 – Установка TortoiseHg и 7 – Импорт файлов репозитория, для копирования файлов на второй, третий и следующие ваши рабочие компьютеры.

Подключение сотрудников к вашему репозиторию.

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

Поэтому давайте сейчас подключим к нашему проекту еще одного программиста (пригласим участника) и настроим ему рабочее место.

Подключение сотрудника к нашему репозиторию

18. Все сотрудники, которые будут иметь доступ к вашему репозиторию, должны быть зарегистрированы на сервисе Bitbucket. А также у них на компьютерах должен быть установлен TortoiseHg.

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

19. Зайдите в ваш аккаунт на сервисе Bitbucket:

Нажмите на кнопку «Отправить приглашение», расположенную в разделе «Пригласить участника на этот репозиторий».

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

После того, как ввели email сотрудника и указали права доступа, жмите кнопку «Share».

21. Приглашенный участник получит на свой email письмо со ссылкой на приглашение. Ему будет необходимо пройти по данной ссылке и принять приглашение на доступ к вашему репозиторию.

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

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

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

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

Данный подход мы применили для разработки проекта.

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

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

Вернуться в

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

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

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

Что такое 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

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

Что это такое?

Итак, системы управления версиями (СУВ) - это такая программка, которая позволяет сохранять всю историю разработки проекта.

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

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

К примеру, недавно у меня начали падать ограничения по скорости в проекте на FPGA. Я буквально за 5 минут нашел версию, в которой они еще не падали и нашел в чем причина

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

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

Какую выбрать?

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

Кроме Mercurial, сейчас довольно распространены git и svn . Git больше распространен в около linux"овской тусовке, svn - в корпоративной среде. Я их попробовал использовать (правда, очень не долго), но ничего такого, из-за чего стоило бы бросать mercurial я не увидел.

Есть такой сайт , на нем можно хранить ваши проекты. Он примечателен тем, что там, в отличии от github можно бесплатно создавать закрытые репозитории (репозиторий - место, где хранится проекты). Платить нужно только за те проекты, которые закрыты и над которыми работает больше, чем 5 человек. При этом, лимит можно расширить до 8ми, рассылая приглашения. Я, пока, не превышал этого лимита. Кроме этого, есть wiki и багтрекер, вообщем, все, что нужно для разработки проектов.

Когда я начинал с ним работать, сайт поддерживал только Mercurial (отчасти из-за этого, я и выбрал mercurial), но сейчас там можно создавать и git-репозитории. Кроме того, к bitbucket можно привязать свой домен. Вот, к примеру, мой вариант: hg.bsvi.ru

Как начать?

Сначала нужно скачать клиент. Я использую tortoiseHg . Думаю, с установкой проблем не возникнет.

После установки, неплохо бы задать имя пользователя по умолчанию. Для этого, нужно отредактировать файл С:/Users/BSVi/mercurial.ini туда нужно добавить строчку

Username = bsvi

Естественно, bsvi нужно заменить на ваше имя.

Теперь мы готовы создать проект и начать что-то делать. Для этого на жмем «Create repository»:

Там заполняем название, описание, выбираем язык. Можно добавить wiki и багтрекер.

Теперь жмем на кнопку «clone» и копируем то, что там появилось:

Дальнейшие операции зависят от того, какой файловый менеджер вы используете. Лично я использую far. Я просто вставляю скопированную строчку в коммандную строку:

Если вы испольуете проводник (эм), total commander или что-то в таком духе, то нужно щелкнуть правой кнопкой мышки и выбрать:


Там, в поле source нужно вставлять путь, естественно, без hg clone:

Вас спросят о вашем пароле, и появится директория test-repo, в которой, собственно и будет находиться проект.

Добавим немного файлов

Если у вас уже есть наработки по проекту, их можно просто скопировать в директорию. Мы-же, для учебных целей, создадим файл main.c с вот таким содержимым:

#include int main() { return 0; }

Теперь сделаем коммит. Коммит - это внесение изменений в проект. Для этого запускаем hg workbench. Я просто пишу в командной строке thg, для эксплорерообразных файловых менеджеров нужно нажать ПКМ->Hg Workbench.

Напротив нашего файла будет знак вопроса (это значит, он не добавлен в проект). Поставим около него галочку и напишем описание того, что было сделано:


Естественно, после этого, жмем кнопку «commit».

Все, изменения в проект внесены. Тут нужно обратить внимание, что изменения внечены только на локальном компьютере (тоесть, их еще нету на сервере). Для того, чтобы перенести изменения на сервер, нужно нажать кнопку «push», вот она:

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

Изменим файл

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

#include int main() { printf("mercurial rules!"); return 0; }

Перейдем в hg workbench. Я когда работаю над проектом его даже не закрываю (об этом-дальше), нажимаем f5 чтобы обновить список файлов. Теперь видно, что изменилось со времени последнего коммита:

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

А что делать с мусором?

При работе над проектом появляется очень много мусора - к примеру, объектные файлы, файлы, которые генерирует IDE, какие-то временные файлы, итп. Все, то, что не относится к самому проекту, неплохо бы убрать из репозитория. Для этого существует файл.hgignore (да, с точкой в начале названия).

Добавим мусорный файл к проекту. Я, к примеру, создал main.obj:

Если сейчас обновить список файлов, то, естественно, hg workbench предложит добавить этот файл в проект:

Теперь, создадим файл.hgigonre и напишем там, что мы хотим игнорировать все файлы с расширением obj:
syntax:glob *.obj

Если обновить список файлов, то obj файлы пропадут, зато появится файл.hgignore, который можно закоммитить:

А как откатить изменения?

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

Точно практически так-же можно откатить отдельный файл.

Заключение

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

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

Для примера, вот скриншот моего UTC (который я разрабатываю сам) в самом сложном месте в hg workbench:

Основы VCS

Введение

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

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

Что такое контроль версий, и зачем он вам нужен?

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

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

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

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

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

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

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

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

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

Централизованные системы контроля версий

Следующей основной проблемой оказалась необходимость сотрудничать с разработчиками за другими компьютерами. Чтобы решить её, были созданы централизованные системы контроля версий (ЦСКВ). В таких системах, например CVS, Subversion и Perforce, есть центральный сервер, на котором хранятся все файлы под версионным контролем, и ряд клиентов, которые получают копии файлов из него. Много лет это было стандартом для систем контроля версий.

Такой подход имеет множество преимуществ, особенно над локальными СКВ. К примеру, все знают, кто и чем занимается в проекте. У администраторов есть чёткий контроль над тем, кто и что может делать, и, конечно, администрировать ЦСКВ намного легче, чем локальные базы на каждом клиенте. Однако при таком подходе есть и несколько серьёзных недостатков. Наиболее очевидный - централизованный сервер является уязвимым местом всей системы. Если сервер выключается на час, то в течение часа разработчики не могут взаимодействовать, и никто не может сохранить новой версии своей работы. Если же повреждается диск с центральной базой данных и нет резервной копии, вы теряете абсолютно всё - всю историю проекта, разве что за исключением нескольких рабочих версий, сохранившихся на рабочих машинах пользователей.

CVS

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

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

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

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

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

Subversion

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

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

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

И в этой ситуации в игру вступают распределённые системы контроля версий (РСКВ). В таких системах как Git, Mercurial, Bazaar или Darcs клиенты не просто выгружают последние версии файлов, а полностью копируют весь репозиторий. Поэтому в случае, когда "умирает" сервер, через который шла работа, любой клиентский репозиторий может быть скопирован обратно на сервер, чтобы восстановить базу данных. Каждый раз, когда клиент забирает свежую версию файлов, он создаёт себе полную копию всех данных.

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

Зачем нужны распределенные системы?

Как следует из названия одна из основных идей распределенных систем - это отсутствие четко выделенного центрального хранилища версий - репозитория. В случае распределенных систем набор версий может быть полностью, или частично распределен между различными хранилищами, в том числе и удаленными. Такая модель отлично вписывается в работу распределенных команд, например, распределенной по всему миру команды разработчиков работающих над одним проектом с открытым исходным кодом. Разработчик такой команды может скачать себе всю информацию по версиям и после этого работать только на локальной машине. Как только будет достигнут результат одного из этапов работы, изменения могут быть залиты в один из центральных репозиториев или, опубликованы для просмотра на сайте разработчика, или в почтовой рассылке. Другие участники проекта, в свою очередь, смогут обновить свою копию хранилища версий новыми изменениями, или попробовать опубликованные изменения на отдельной, тестовой ветке разработки. К сожалению, без хорошей организации проекта отсутствие одного центрального хранилища может быть минусом распределенных систем. Если в случае централизованных систем всегда есть один общий репозиторий откуда можно получить последнюю версию проекта, то в случае распределенных систем нужно организационно решить какая из веток проекта будет основной. Почему распределенная система контроля версий может быть интересна кому-то, кто уже использует централизованную систему - такую как Subversion? Любая работа подразумевает принятие решений, и в большинстве случаев необходимо пробовать различные варианты: при работе с системами контроля версий для рассмотрения различных вариантов и работы над большими изменениями служат ветки разработки. И хотя это достаточно естественная концепция, пользоваться ей в Subversion достаточно не просто. Тем более, все усложняется в случае множественных последовательных объединений с одной ветки на другую - в этом случае нужно безошибочно указывать начальные и конечные версии каждого изменения, что бы избежать конфликтов и ошибок. Для распределенных систем контроля версий ветки разработки являются одной из основополагающих концепций - в большинстве случаев каждая копия хранилища версий является веткой разработки. Таким образом, механизм объединения изменений с одной ветки на другую в случае распределенных систем является одним из основных, что позволяет пользователям прикладывать меньше усилий при пользовании системой.

Краткое описание популярных распределенных СУВ

• Git - распределенная система контроля версий, разработанная Линусом Торвальдсом. Изначально Git предназначалась для использования в процессе разработки ядра Linux, но позже стала использоваться и во многих других проектах - таких, как, например, X.org и Ruby on Rails, Drupal. На данный момент Git является самой быстрой распределенной системой, использующей самое компактное хранилище ревизий. Но в тоже время для пользователей, переходящих, например, с Subversion интерфейс Git может показаться сложным;
• Mercurial - распределенная система, написанная на языке Python с несколькими расширениями на C. Из использующих Mercurial проектов можно назвать, такие, как, Mozilla и MoinMoin.
• Bazaar - система разработка которой поддерживается компанией Canonical - известной своими дистрибутивом Ubuntu и сайтом https://launchpad.net/ . Система в основном написана на языке Python и используется такими проектами, как, например, MySQL.
• Codeville - написанная на Python распределенная система использующая инновационный алгоритм объединения изменений (merge). Система используется, например, при разработке оригинального клиента BitTorrent.
• Darcs - распределенная система контроля версий написанная на Haskell используемая, например, проектом Buildbot.
• Monotone - система написанная на C++ и использующая SQLite как хранилище ревизий.