Иван Немытченко , 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
Системы контроля версий нацелены в первую очередь на работу с большим количеством небольших файлов, что используется в основном в разработке. Использование подобных систем для файлов нетекстовых форматов (бинарных), как правило, неэффективно, а в некоторых случаях и вовсе невозможно. Поэтому для хранения других файлов используются обычно специализированные системы, адаптированные под работу с определенными форматами данных.

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

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

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

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

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

Рисунок 1-1. Схема локальной СКВ.

Одной из наиболее популярных СКВ такого типа является rcs, которая до сих пор устанавливается на многие компьютеры. Даже в современной операционной системе Mac OS X утилита rcs устанавливается вместе с Developer Tools. Эта утилита основана на работе с наборами патчей между парами версий (патч - файл, описывающий различие между файлами), которые хранятся в специальном формате на диске. Это позволяет пересоздать любой файл на любой момент времени, последовательно накладывая патчи.

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

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

Рисунок 1-2. Схема централизованного контроля версий.

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

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

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

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

Рисунок 1-3. Схема распределённой системы контроля версий.

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

Система контроля версий (Version Control System, VCS ) представляет собой программное обеспечение, которое позволяет отслеживать изменения в документах, при необходимости производить их откат, определять, кто и когда внес исправления и т.п. В статье рассмотрены виды VCS , принципы их работы, а также приведены примеры программных продуктов.

Что такое система контроля версий?

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

Для решения таких проблем как раз и используется система контроля версий, она позволяет комфортно работать над проектом как индивидуально, так в коллективе. VCS отслеживает изменения в файлах, предоставляет возможности для создания новых и слияние существующих ветвей проекта, производит контроль доступа пользователей к проекту, позволяет откатывать исправления и определять кто, когда и какие изменения вносил в проект. Основным понятием VCS является репозиторий (repository ) – специальное хранилище файлов и папок проекта, изменения в которых отслеживаются. В распоряжении разработчика имеется так называемая “рабочая копия” (working copy ) проекта, с которой он непосредственно работает. Рабочую копию необходимо периодически синхронизировать с репозиторием, эта операция предполагает отправку в него изменений, которые пользователь внес в свою рабочую копию (такая операция называется commit ) и актуализацию рабочей копии, в процессе которой к пользователю загружается последняя версия из репозитория (этот процесс носит название update ).

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

Системы контроля версий можно разделить на две группы: распределенные и централизованные.

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

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

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

Subversion (SVN ) – система контроля версий, созданная на замену CVS . SVN была разработана в 2004 году и до сих пор используется. Несмотря на многие преимущества по сравнению с CVS у SVN все-таки есть недостатки, такие как проблемы с переименованием, невозможность удаления данных из хранилища, проблемы в операции слияния ветвей и т.д. В целом SVN был (и остается) значительном шагом вперед по сравнению с CVS.

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

Распределенные системы контроля версий (Distributed Version Control System, DVCS ) позволяют хранить репозиторий (его копию) у каждого разработчика, работающего с данной системой. При этом можно выделить центральный репозиторий (условно), в который будут отправляться изменения из локальных и, с ним же эти локальные репозитории будут синхронизироваться. При работе с такой системой, пользователи периодически синхронизируют свои локальные репозитории с центральным и работают непосредственно со своей локальной копией. После внесения достаточного количества изменений в локальную копию они (изменения) отправляются на сервер. При этом сервер, чаще всего, выбирается условно, т.к. в большинстве DVCS нет такого понятия как “выделенный сервер с центральным репозиторием”.

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

Начнем с Mercurial , эта система представляет собой свободную DVCS , которая построена таким образом, что в ней отсутствует понятие центрального репозитория, для работы с этой VCS используется (как правило) консольная утилита hg . Mercurial обладает всеми возможностями системы контроля версий, такими как ветвление, слияние, синхронизация с другими репозиториями. Данный проект используют и поддерживают большое количество крупных разработчиков, среди них Mozilla , OpenOffice , OpenJDK и многие другие. Сам продукт написан на языке Python и доступен на большинстве современных операционных систем (Windows , Mac OS , Linux ), также существует значительное количество утилит с графическим интерфейсом для работы с Mercurial . Основным конкурентом Mercurial на рынке распределенных систем контроля версий является Git , который, на сегодняшний день, выиграл гонку за лидерство.

Git – распределенная система контроля версий, разработанная Линусом Торвальдсем для работы над ядром операционной системы Linux . Среди крупных проектов, в рамках которых используется git , можно выделить ядро Linux , Qt , Android . Git свободен и распространяется под лицензией GNU GPL 2 и, также как Mercurial , доступен практически на всех операционных системах. По своим базовым возможностям git схож с Mercurial (и другими DVCS ), но благодаря ряду достоинств (высокая скорость работы, возможность интеграции с другими VCS , удобный интерфейс) и очень активному сообществу, сформировавшемуся вокруг этой системы, git вышел в лидеры рынка распределенных систем контроля версий. Необходимо отметить, что несмотря на большую популярность таких систем как git , крупные корпорации, подобные Google , используют свои VCS .

Это была вводная лекция по системам контроля версий. В дальнейшем, все изложение будет касаться только git .

Если вам больше нравится учиться по видео-лекциям , то рекомендуем классный курс по git от GeekBrains , перейдите по ссылке и найдите в разделе “Курсы” курс “Git . Быстрый старт” . Он бесплатный , нужно только зарегистрироваться на сайте. Рекомендуем повнимательнее посмотреть на этот ресурс, на нем ещё очень много чего интересного!

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

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

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

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

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

Что такое 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 вы вообще не обойдетесь.

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

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

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

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 прочие, — просто нажав на кнопку.

Вконтакте

Телеграм