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

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

Вернуться в

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

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

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

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

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

Естественно, поиски были начаты с изучения Хабра - и привели к неожиданному результату. Несмотря на то, что системы контроля версий появились ещё в 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, т.е. пройдя все шаги, вы получите хоть и не большой, но законченный результат.

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

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

Версионирование

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

Source/ barbershop_index_final.psd

Всё хорошо, дизайнер закончил работу, но заказчик прислал в ответ правки. Чтобы была возможность вернуться к старой версии проекта, дизайнер создал новый файл barbershop_index_final_2.psd , внёс изменения и отправил заказчику:

Source/ barbershop_index_final.psd barbershop_index_final_2.psd

Этим всё не ограничилось, в итоге структура проекта разрослась и стала выглядеть так:

Source/ barbershop_index_final.psd barbershop_index_final_2.psd … barbershop_index_final_19.psd … barbershop_index_latest_final.psd barbershop_index_latest_final_Final.psd

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

Git

Для решения проблемы с сохранением новой версии файлов удобно использовать системы контроля версий. Одна из самых популярных — Git. Работу Git можно сравнить с процессом сохранения и загрузки в компьютерных играх:

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

SomeGame/ | - saves | | - save001.sav | | - save002.sav | | … | | папка с сохранениями | | - game.exe | ...файлы игры

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

Основные понятия

GUI

Облегчить работу с Git и GitHub могут специальные программы . Такие программы в удобной форме показывают изменения в коде, список коммитов и обладают другими удобными возможностями. Обычно в подобных программах есть возможность выполнять стандартные Git команды: pull , push , commit прочие, — просто нажав на кнопку.

Вконтакте

Телеграм

Вопрос был бы уместен лет 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. Часть 1

Введение

Серия контента:

1. Введение

Во время работы над проектом его участники часто сталкиваются с проблемами синхронизации и ведения истории файлов, решить которые помогают системы управления версиями (СУВ). Цель этой серии статей – познакомить читателя с принципами работы СУВ и подробно рассмотреть одну из них, а именно Git. Почему Git? В последнее время эта система набирает популярность, и ее важность для свободного ПО (и для проекта GNU/Linux, в частности) сложно переоценить.

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

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

В следующих материалах мы углубимся в структуру и философию Git, специфику этой системы и тонкости практической работы с ней. Завершит цикл статья о взаимодействии Git с другими СУВ (такими как Subversion, CVS, Mercurial и др.).

2. Git – это...

Git – это распределённая система управления версиями файлов. Код программы написан в основном на языке С. Проект был создан Линусом Торвальдсом в 2005 году для управления разработкой ядра Linux и, как и GNU/Linux, является свободным программным обеспечением (ПО), при этом стороннее использование подчиняется лицензии GNU GPL версии 2. Вкратце данное соглашение можно охарактеризовать как ПО со свободным кодом, которое должно развиваться открыто, т.е. любой программист вправе продолжить совершенствование проекта на любом его этапе. За свое недолгое время существования данная система была введена многими ведущими разработчиками. Git используется в таких известных Linux-сообществу проектах, как Gnome, GNU Core Utilities, VLC, Cairo, Perl, Chromium, Wine.

3. Системы управления версиями

Системы управления версиями (Version Control Systems) – это программное обеспечение, призванное автоматизировать работу с историей файла (или группы файлов), обеспечить мониторинг изменений, синхронизацию данных и организовать защищенное хранилище проекта. Короче говоря, основная задача систем управления версиями – упростить работу с изменяющейся информацией. Разберем общий вид разработки на примере.

Предположим, есть некий проект, который вы разрабатываете, несколько отделов программистов и вы – координатор (или руководитель). По отношению к системе контроля, будь то сервер (если речь идет о централизованной системе) или локальная машина, любой разработчик проекта ограничен только правами доступа на изменение и/или чтение версий файлов данного хранилища. В любой момент вы можете сделать откат данных до необходимой вам версии. Вы, как координатор, можете ограничить доступ определенным пользователям на обновление версии файла. Также СУВ предоставляет интерфейс наблюдения и поиска версий файлов. Например, можно создать запрос: “Где и когда менялся данный кусок кода?”.

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

4. Отличия распределённых систем управления версиями

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

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

5. Основные возможности и особенности Git

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

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

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

Выделим основные отличия Git от других распределенных и централизованных СУВ.

Архитектура Git

SHA1 (Secure Hash Algorithm 1) – это алгоритм криптографического хеширования. Каждый файл вашего проекта в Git состоит из имени и содержания. Имя – это первые 20 байтов данных, оно наглядно записывается сорока символами в шестнадцатеричной системе счисления. Данный ключ получается хешированием содержимого файла. Так, например, сравнив два имени, мы можем почти со стопроцентной вероятностью сказать, что они имеют одинаковое содержание. Также, имена идентичных объектов в разных ветвях (репозиториях) – одинаковы, что позволяет напрямую оперировать данными. Хорошим дополнением сказанному выше служит ещё то, что хеш позволяет точно определить поврежденность файлов. Например, сравнив хеш содержимого с именем, мы можем вполне точно сказать, повреждены данные или нет. Далее под именем мы будем понимать имя файла, а строку символов будем называть SHA1-хешем.

Стоит упомянуть о так называемых коллизиях. “Вполне точно определить поврежденность” означает, что существуют такие файлы, различные по содержанию, SHA1-хеш которых совпадает. Вероятность таких коллизий очень мала, и по предварительной оценке равна 2 в -80-й степени (~ 10 в -25-й степени). Точной оценки нет, так как на данный момент мировому сообществу не удалось эффективно расшифровать данную криптографическую схему.

Объекты Git

Работу с версиями файлов в Git можно сравнить с обычными операциями над файловой системой. Структура состоит из четырех типов объектов: Blob, Tree, Commit и References; некоторые из них, в свою очередь, делятся на подобъекты.

Blob (Binary Large Object) – тип данных, который вмещает лишь содержимое файла и собственный SHA1-хеш. Blob является основным и единственным носителем данных в структуре Git. Можно провести параллель между данным объектом и инодами (inodes) в файловых системах, поскольку их структура и цели во многом схожи.

Дерево (Tree)

• собственный SHA1-хеш;
• SHA1-хеш blob’ов и/или деревьев;
• права доступа Unix-систем;
• символьное имя объекта (название для внутреннего использования в системе).

По своей сути объект является аналогом директории. Он задает иерархию файлов проекта.

Commit – тип данных, который содержит:

• собственный SHA1-хеш;
• ссылку ровно на одно дерево;
• ссылку на предыдущий commit (их может быть и несколько);
• имя автора и время создания commit’а;
• имя коммитера (commiter – человек, применивший commit к репозиторию, он может отличаться от автора) и время применения commit’а;
• произвольный кусок данных (блок можно использовать для электронной подписи или, например, для пояснения изменений commit’а).

Данный объект призван хранить снимок (версию) группы файлов в определенный момент времени, можно сравнить его с контрольной точкой. Commit’ы можно объединять (merge), разветвлять (branch) или, например, установить линейную структуру, тем самым отражая иерархию версий проекта.

Reference – тип данных, содержащий ссылку на любой из четырех объектов (Blob, Tree, Commit и References). Основная цель его – прямо или косвенно указывать на объект и являться синонимом файла, на который он ссылается. Тем самым повышается понимание структуры проекта. Очень неудобно оперировать бессмысленным набором символов в названии, ссылку же, в отличие от SHA1-хеша, можно именовать так, как удобнее разработчику.

Из ссылок, в свою очередь, можно выделить ряд подобъектов, имеющих некоторые различия: Ветвь, Тег. Рассмотрим их.

Ветвь (Head, Branch) – символьная ссылка (Symbolic link), которая указывает на последний в хронологии commit определенной ветви и хранит SHA1-хеш объекта. Является типом данных журналируемых файловых систем. Данный вид объекта определяется не в самом Git, а наследуется от операционной и файловой систем. Ветвь используется как синоним файла, на который она ссылается, т.е. Git позволяет оперировать ею напрямую. Можно позволить себе не задумываться о том, работаете ли вы с последней версией или нет.

Тег (tag) – тип данных, который в отличие от ветвей неизменно ссылается на один и тот же объект типа blob, tree, commit или tag. Его, в свою очередь, можно разделить на легковесный (light tag) и тяжеловесный или аннотированный (annotated tag). Легкий тег, кроме неизменности ссылки, ничем не отличается от обычных ветвей, т.е. содержит лишь SHA1-хеш объекта, на который ссылается, внутри себя. Аннотированный тег состоит из двух частей:

• первая часть содержит собственный SHA1-хеш;
• вторая часть состоит из:
  • SHA1 объекта, на который указывает аннотированный тег;
  • тип указываемого объекта (blob, tree, commit или tag);
  • символьное имя тега;
  • дата и время создания тега;
  • имя и e-mail создателя тега;
  • произвольный кусок данных (данный блок можно использовать для электронной подписи или для пояснения тега).

Иными словами, проект в Git представляет собой набор blob’ов, которые связаны сетью деревьев. Полученная иерархическая структура может, в зависимости от времени, быть отражена в виде commit’ов – версий, а для понимания их структуры в Git присутствуют такие объекты, как ссылки. Исключая действия со ссылками, почти вся работа с объектами системы максимально автоматизирована изнутри. Отталкиваясь от механизма ссылок, мы приходим к следующей идее – работать именно над группами файлов. По мнению автора, мысль является ключевой в философии Git. Задав, например, операцию для данного commit’а, она рекурсивно отработает свою часть по дереву, на которое ссылается. Являясь расширением общепринятого взгляда “действие над каждым файлом”, нововведение упрощает реализацию и подход со стороны программиста над повседневными задачами СУВ, такими как слияние/разделение ветвей, опять же рекурсивно автоматизируя процесс. Данный подход прост для понимания, быстро работает и гибок в реализации своих целей. Многие из этих черт достигаются благодаря Unix-ориентированности системы, т.е. оперируя стандартными устройствами, Git опирается на уже имеющиеся в операционной системе решения.

Проясним момент хранения данных. Содержание файлов разных версий в хронологии занимает довольно много памяти. Так, например, в проекте из двадцати файлов двадцати версий архив будет весить в 20 раз больше (возможно, порядка сотни мегабайтов), а что будет, если количество и тех и других в 10 раз больше (вроде бы не намного)? Размер занятого пространства возрастет в 100 раз (т.е. примерно 1 ГБ). В реальных задачах скорость роста занимаемой памяти далеко не линейно зависит от времени. Для решения данной проблемы существует несколько оптимизаций:

• каждый объект Git хранится в виде обыкновенного архива (tar.gz);
• для всей иерархии файлов применяется последовательная дельта-компрессия.

Разберем на примере.

У вас есть трехлетняя история вашего проекта, в ней порядка тысячи файлов и ста версий. Если в определенный момент нужно будет обратиться к самой ранней версии, Git придется разархивировать дельта-компрессию всей истории файла. Неутешительно, но на данный процесс может уйти до полудня. Git предлагает делать так называемые контрольные точки, т.е. хранить недельта-архивированный файл через некоторое количество версий, которое назовем глубиной компрессии. Тогда в нашем примере вся история сужается до некоторого наперед заданного количества дельта-компрессий, разархивировав которые, можно взглянуть на любую версию в хронологии. Заметим, что дельта-компрессию наиболее целесообразно использовать над одними видами ближайших в иерархии объектов, для этого репозиторий необходимо отсортировать соответственно по типу и размеру. Данный ряд операций, описанных в этом пункте, выполняет функция git-repack (и git-gc, которая её содержит).

Слияние и разделение ветвей

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

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

Пусть мы получили два уже законченных результата одной и той же задачи, над которой работали две группы программистов. Как нам быть? Посмотреть, чей код быстрее и надежнее? Это слишком просто, но не всегда лучший выход. Хорошее решение – это, немного разобравшись в коде и файлах, разбить их на подзадачи или блоки кода. И только тогда уже выявлять сильные и слабые стороны данных кусочков. Конечно, этот вариант подходит только в том случае, когда вы заранее предусмотрели, что впоследствии сможете собрать все эти частицы воедино. Случай, когда вы сами разрабатываете код, улучшая и исправляя некоторые ошибки, равнозначен приведенному примеру. Данный процесс объединения двух целых в одно называется слияние (merge). Процесс объединения двух версий и есть ключевой момент ведения проекта. Как бы то ни было, стоит избегать автоматизированного исполнения данной операции. Отличительная черта Git – это максимально достоверный и довольно быстрый способ решения задачи ветвления.

К достоинствам системы можно отнести:

1. Unix-ориентированность.
2. Идеологическая выдержанность (следуя правилам использования системы, очень сложно попасть в безвыходную ситуацию или получить то, чего вы не ожидали).
3. Высокая производительность (это одно из самых явных достоинств системы, плата за которое есть «Идеологическая выдержанность» и «Unix-ориентированность»).
4. Интеграция Git со сторонними СУВ, такими как Subversion, Mercurial, …
5. Управление группой файлов (системе нет необходимости рассматривать изменения в каждом файле по отдельности, она запоминает любые изменения всего проекта, и если вдруг вам понадобится проследить единичные изменения, она выдаст ровно ту часть, которая связана с данным файлом).
6. Операция слияния (максимально автоматизированная реализация сложной задачи).

К недостаткам отнесем:

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

6. Интерфейсы Git

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

Для людей, которые не занимаются разработкой вплотную, для «консерваторов» – тех, кто любит “кнопочки и галочки” и сознательно хочет оградить себя от непомерных усилий запоминания функций, ключей и многих тонкостей, больше подойдет вариант в стиле TortoiseGit или Git Extensions – простые интерфейсы. Они позволяют действовать преимущественно мышью и работают в привычной для многих ОС Windows.

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

Можно выделить и третий тип интерфейсов – смешение первых двух. Т.е. у вас есть консольное приложение, например, “родная” оболочка git. Вы можете использовать ряд дополнительных утилит, таких как Gitk или QGit, для отображения деревьев, упрощения обзора иерархии версий, различий между версиями, поиска нужных объектов.