Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Министерство образования и науки Российской Федерации

Федеральное государственное бюджетное образовательное

Учреждение высшего профессионального образования

«ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

СИСТЕМ УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ» (ТУСУР)

Кафедра радиотехнических систем (РТС)

Курсовая работа

по курсу «Информационные технологии»

СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ

Студенты гр.121-3 Королев Д.О.,

Кулешов М.В., Садов Д.А., Таймасов С.С.

Руководитель Ноздреватых Б.Ф

Курсовая работа 46с., 31 рис., 2 табл., источников.

СИСТЕМА КОНТРОЛЯ ВЕРСИЙ, GIT, SVN, MERCURIAL.

В данной курсовой работе рассматриваются наиболее популярные системы контроля версий.

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

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

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

Курсовая работа выполнена в текстовом редакторе Microsoft Word 2010 и представлена в печатном и электронном виде.

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

Введение

3.1 Начало работы с проектом

3.2 Ежедневный цикл работы

3.3 Ветвления

3.4 Слияние версий

3.5 Конфликты и их разрешение

3.6 Блокировки

3.7 Версии проекта, теги

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

4.2 Централизованная модель

5.1.1 Требования к системе

5.1.2 Концепция

5.1.3 Начало работы

5.2.1 Требования к системе

5.2.2 Установка

5.2.3 Основная концепция

5.2.4 Создание хранилища

5.2.5 Импорт проекта

5.2.7 Внесение изменений

5.2.8 Добавление новых файлов

5.2.9 Отмена изменений

5.3.1 Требования к системе

5.3.2 Концепция

5.3.3 Начало работы

Заключение

Приложение А

Приложение Б

Приложение В

Введение

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

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

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

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

В соответствии с поставленной целью необходимо решить следующие задачи:

Определить понятие системы контроля версий;

Понять, как работают такие системы;

Рассмотреть правила установки и запуска;

Проанализировать существующие системы контроля версий;

Рассмотреть основные виды данного рода систем.

Задачи работы предопределили ее структуру. Курсовая работа состоит из пяти глав, введения, заключения, списка литературы и приложения.

1. Понятие системы контроля версий

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

2. Использование системы контроля версий

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

Использование СКВ, безусловно, обязательно для разработчика, если проект больше нескольких сот строк или если для проекта совместно работают несколько разработчиков.

Системы контроля версий решают следующие проблемы:

Хранение версий файлов;

Возможность получить любые предыдущие версии хранимых файлов;

Просмотр изменений внесенных между заданными в запросе версиями;

3. Типичный порядок работы с системой

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

3.1 Начало работы с проектом

Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью стандартной команды извлечения версии (checkout или clone) либо специальной команды, фактически выполняющей то же самое действие. Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.

По команде извлечения устанавливается соединение с сервером, и проект в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была сделана рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения СКВ.

3.2 Ежедневный цикл работы

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

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

2) Модификация проекта. Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием. Эта работа производится локально и не требует обращений к серверу СКВ.

3) Фиксация изменений. Завершив очередной этап работы над заданием, разработчик фиксирует (commit) свои изменения, передавая их на сервер, либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания. СКВ может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в СКВ это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.

3.3 Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксацией изменений прямо в главной ветви (стволе) на сервере. Однако при выполнении сколько-нибудь значительных по объёму работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch), создание версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в основную ветвь. Это может делаться командой слияния (merge), либо путём создания патча (patch), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.

3.4 Слияние версий

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

Обновление рабочей копии;

Фиксация изменений;

Слияние ветвей.

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

Изменения могут состоять в модификации содержимого файла, создании нового файла или каталога, удалении или переименовании ранее существовавшего файла или каталога в проекте;

Если два изменения относятся к разным и не связанным между собой файлам и/или каталогам, они всегда могут быть объединены автоматически. Их объединение состоит в том, что изменения, сделанные в каждой версии проекта, копируются в объединяемую версию;

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

Конфликтующими обычно являются:

Удаление и изменение одного и того же файла или каталога;

Удаление и переименование одного и того же файла или каталога;

Создание в разных версиях файла с одним и тем же именем и разным содержимым;

Изменения в пределах одного текстового файла, сделанные в разных версиях, могут быть объединены, если они находятся в разных местах этого файла и не пересекаются. В этом случае в объединённую версию вносятся все сделанные изменения;

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

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

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

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

3.5 Конфликты и их разрешение

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

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

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

3.6 Блокировки

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

Файлы, для работы с которыми требуется блокировка, помечаются специальным флагом «блокируемый»;

Если файл помечен как блокируемый, то при извлечении рабочей копии с сервера он получает в локальной файловой системе атрибут «только для чтения», что препятствует его случайному редактированию;

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

1. сервер проверяет, не заблокирован ли уже файл другим разработчиком; если это так, то команда блокировки завершается с ошибкой.

2. файл на сервере помечается как «заблокированный», с сохранением идентификатора заблокировавшего его разработчика и времени блокировки;

3. если блокировка на сервере прошла удачно, на локальной файловой системе с файла рабочей копии снимается атрибут «только для чтения», что позволяет начать его редактировать.

Если в процессе работы выясняется, что файл изменять не нужно, он может вызвать команду снятия блокировки (unlock, release lock). Все изменения файла будут отменены, локальный файл вернётся в состояние «только для чтения», с файла на сервере будет снят атрибут «заблокирован» и другие разработчики получат возможность изменять этот файл;

По завершении работы с блокируемым файлом разработчик фиксирует изменения. Обычно блокировка при этом снимается автоматически.

3.7 Версии проекта, теги

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

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

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера. Номера версии отдельного файла здесь, фактически, не существует.

Однако оба варианта не слишком удобны. Для более удобной пометки версий проекта системы контроля версиями поддерживают понятие тегов.

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

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

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

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

Одной из наиболее популярных СКВ такого типа является RCS, которая до сих пор устанавливается на многие компьютеры.

4.2 Централизованная модель

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

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

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

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

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

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

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

Рисунок 4.3 Распределённая модель СКВ

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

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

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

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

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

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

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

- Слежение за определённым файлом или группой файлов;

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

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

Можно выделить следующие типичные ситуации, в которых использование распределённой системы даёт заметные преимущества:

- Периодическая синхронизация нескольких компьютеров под управлением одного разработчика. Использование распределённой системы избавляет от необходимости выделять один из компьютеров в качестве сервера;

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

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

5. Примеры систем контроля версий

5.1 GIT

5.1.1 Требования к системе

Git работает под следующими операционными системами: Windows, Linux и Mac OS.

Для того, чтобы установить Git в Windows, требуется просто скачать exe-файл инсталлятора со страницы проекта на GitHub"е и запустите его. После установки у вас будет как консольная версия (включающая SSH-клиент), так и стандартная графическая.

5.1.2 Концепция

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

Таким образом, в проектах, использующих Git, есть три части: каталог Git"а (Git directory), рабочий каталог (working directory) и область подготовленных файлов (staging area).

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

Рабочий каталог -- это извлечённая из базы копия определённой версии проекта. Эти файлы достаются из сжатой базы данных в каталоге Git"а и помещаются на диск для того, чтобы вы их просматривали и редактировали.

Область подготовленных файлов -- это обычный файл, обычно хранящийся в каталоге Git"а, который содержит информацию о том, что должно войти в следующий коммит. Иногда его называют индексом (index), но в последнее время становится стандартом называть его областью подготовленных файлов (staging area).

Стандартный рабочий процесс с использованием Git"а выглядит примерно так:

1. Вы вносите изменения в файлы в своём рабочем каталоге.

2.Подготавливаете файлы, добавляя их слепки в область подготовленных файлов.

3. Делаете коммит, который берёт подготовленные файлы из индекса и помещает их в каталог Git"а на постоянное хранение.

Если рабочая версия файла совпадает с версией в каталоге Git"а, файл считается зафиксированным. Если файл изменён, но добавлен в область подготовленных данных, он подготовлен. Если же файл изменился после выгрузки из БД, но не был подготовлен, то он считается изменённым.

5.1.3 Начало работы

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

1. Через контекстное меню. Для этого нужно просто кликнуть правой кнопкой мыши в нужной директории и выбрать пункт Git Init Here.

Рисунок 5.1.1 Создание репозитория при помощи контекстного меню

2. С помощью командной строки. Для этого аналогично, в требуемой директории, в контекстном меню выбрать Git Bash. Откроется командная строка в которой создаем репозиторий при помощи команды Git Init.

Рисунок 5.1.2 Создание репозитория при помощи командной строки

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

git config --global user.name "Your Name"

git config --global user.email [email protected]

Созданный репозиторий будет содержать директорию.git. Чтобы добавить файл в репозиторий требуется просто скопировать его в рабочую директорию. Добавим файл ex.txt в репозиторий. С помощью команды git status убедимся, что Git увидел файл.

Рисунок 5.1.3 Добавление и проверка файла в репозитории

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

Рисунок 5.1.4 Добавление файла под версионный контроль

Команда git status - основной инструмент, используемый для определения, какие файлы в каком состоянии находятся.

Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add «имя файла». Эта команда принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.

Git commit -m «комментарий» - команда для создания коммита, фиксирования изменения.

Через графический интерфейс Git Gui повторим предыдущую операцию. Для это в контекстном меню выберем пункт Git Gui.

Рисунок 5.1.5

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

Рисунок 5.1.6 Создание репозитория в Git Gui

Добавляем файл Ex.txt в каталог. Далее нажимаем кнопку «Перечитать». Для добавления файла в систему контроля версий требуется нажать кнопку «Подготовить все». Файл Ex.txt должен переместится из окна «изменено» в «Подготовлено». Для фиксирования изменения используется кнопка «Сохранить».

5.1.5 Создание копии репозитория

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

В этом разделе рассмотрим процесс создания учётной записи и нового проекта на GitHub"е. Это даст вам представление о вовлечённых в него вещах.

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

Первое, что нужно сделать, это настроить учётную запись и создать свой репозиторий на сайте http://github.com/plans.

Далее в командной строке Git вводим уже известные нам команды:

Git add ex.txt

Git commit -m "комментарий"

Git remote add origin https://github.com/Arbuz-z-z/MyHomework.git

Git push -u origin master

Команда git remote add - добавление удалённых репозиториев, а команда git push - отправление локальных изменений на удаленный сервер.

Рисунок 5.1.7

Вводим логин и пароль указанные при регистрации:

Рисунок 5.1.8

Теперь наш проект размещён на GitHub"е, в репозитории - MyHomework с файлом Tusur.txt и мы можем дать ссылку на него любому, с кем захотим разделить проект.

Рисунок 5.1.9 Репозиторий на GitHub"е

5.2 TortoiseSVN

5.2.1 Требования к системе

TortoiseSVN работает под операционной системой Windows XP (c Service Pack 3) или выше, и доступен как в 32-битной, так и в 64-битной версии. Установщик для 64-битной Windows также включает 32-битную часть.

5.2.2 Установка

TortoiseSVN поставляется в виде простого в использовании установочного файла.

5.2.3 Основная концепция

Хранилище. Subversion использует центральную базу данных, которая содержит все версированные файлы с их полной историей. Эта база данных называется хранилищем. Хранилище обычно находится на файловом сервере, на котором установлен Subversion, по запросу поставляющий данные клиентам Subversion (например, TortoiseSVN). Если вы делаете резервное копирование, то копируйте ваше хранилище, так как это оригинал всех ваших данных.

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

TortoiseSVN - расширение проводника Windows, поэтому для начала нужно запустить проводник.

Рисунок 5.2.1 Вид в проводнике

5.2.4 Создание хранилища

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

Сначала создадим новую пустую директорию на ПК. Она может быть где угодно, но в этой работе мы собираемся назвать её s:\svn_repos. Теперь сделав правый клик на новой папке и в контекстном меню выберем TortoiseSVN > Создать здесь хранилище... Хранилище, созданное внутри папки, готово к использованию. Также мы создадим внутреннюю структуру папок, нажав кнопку «Создать структуру каталогов».

Рисунок 5.2.2 Создание репозитория

Рисунок 5.2.3 просмотр репозитория

5.2.5 Импорт проекта

Сейчас у нас есть хранилище, но оно совершенно пустое в данный момент. Давайте предположим, что у нас есть набор файлов в E:\ \TortoiseSVN, который мы хотели бы добавить. Перейдём к папке TortoiseSVN в Проводнике и сделаем правый клик на ней. Теперь выберем пункт TortoiseSVN > Импорт..., который вызовет диалоговое окно.

Рисунок 5.2.4 Окно импорта

К хранилищу Subversion обращаются по URL-адресу, который позволяет нам указать хранилище где угодно в Интернете. В данном случае нам нужно указать на наше локальное хранилище, которое имеет URL-адрес file:///s:/svn_repos, и к которому мы добавляем имя нашего проекта TortoiseSVN.

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

5.2.6 Извлечение рабочей копии

Сейчас у нас есть проект в нашем хранилище, и нам надо создать рабочую копию для повседневной работы. Стоит отметить, что импортирование папки не превращает автоматически эту папку в рабочую копию. Для создания свежей рабочей копии в Subversion используется термин «Извлечь». Мы собираемся извлечь папку TortoiseSVN из нашего хранилища в папку для разработки называемую e:\ \TortoiseSVN\svn_repos. Создадим эту папку, затем сделаем правый клик на ней и выберите пункт TortoiseSVN > Извлечь... Введите URL-адрес для извлечения, в данном случае file:///s:/svn_repos/TortoiseSVN, и кликните на OK. Наша папка для разработки заполнится файлами из хранилища.

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

5.2.7 Внесение изменений

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

Нажав правой кнопкой на одном из изменённых файлов, выберем команду TortoiseSVN > Различия. Запустится инструмент TortoiseSVN для сравнения файлов и покажет, какие точно строки в файлах были изменены.

Рисунок 5.2.5 Сравнение файлов

Теперь обновим хранилище. Это действие называется «Фиксировать изменения». Нажмём правой кнопкой на папке TortoiseSVN и выберем команду TortoiseSVN > Фиксировать. Появится диалог фиксации со списком изменённых файлов и напротив каждого будет галочка. Мы можем выбрать лишь несколько файлов из списка для фиксации.

Рисунок 5.2.6 Фиксация файлов

5.2.8 Добавление новых файлов

Во время работы над проектом, нам понадобится добавлять новые файлы, предположим мы добавили новые функции в файле и добавили справку в существующем файле. Нажмём правой кнопкой на папке и выберите команду TortoiseSVN > Добавить. Диалог добавления показывает все неверсированные файлы и мы можем выбрать те файлы, которые мы хотим добавить. Другой способ добавления файлов - это нажать правой кнопкой на самом файле и выбрать команду TortoiseSVN > Добавить.

Теперь, если мы откроем папку для фиксации, новый файл будет отображаться, как «Добавлен» и существующий файл как «Изменён».

5.2.9 Отмена изменений

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

Если мы хотим избавиться от изменений, которые мы еще не успели фиксировать и восстановить нужный файл в том виде, в котором он был перед началом изменений, то выберем команду TortoiseSVN > Убрать изменения. Это действие отменит наши изменения и вернет фиксированную версию файла, с которой мы начинали. Если же мы хотим убрать лишь некоторых изменения, то мы можете использовать инструмент TortoiseMerge для просмотра изменений и выборочного удаления измененных строк.

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

5.2.10 Возможности TortoiseSVN. Интеграция с оболочкой

TortoiseSVN интегрируется непосредственно в оболочку Windows (т.е. в Проводник). Это значит, что вы можете работать с уже знакомыми инструментами, и вам не надо переключаться на другое приложение каждый раз, когда вам необходимы функции для управления версиями!

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

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

5.2.11 Графический интерфейс пользователя

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

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

Все команды Subversion доступны из контекстного меню Проводника. TortoiseSVN добавляет туда собственное подменю.

5.3 Mercurial

5.3.1 Требования к системе

П акеты Mercurial доступны для каждой популярной операционной системы: Windows, Mac OS, Linux (Ubuntu, Debian, Fedora, OpenSUSE, Gentoo), Solaris.

Лучшей версией Mercurial для Windows является TortoiseHg, который можно найти на сайте http://tortoisehg.org. Этот пакет позволяет использовать командную строку и графический пользовательский интерфейс.

5.3.2 Концепция

Mercurial является распределенной (децентрализованной) системой контроля версий. Это означает, что рабочий процесс, как правило, выглядит следующим образом:

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

2. В рабочей директории данного репозитория изменяются/добавляются/удаляются файлы;

3. Выполняется фиксация (commit) изменений в данный репозиторий (то есть в локальный репозиторий на личном компьютере);

4. Шаги 2 и 3 повторяются столько раз, сколько необходимо;

5. При необходимости производится синхронизация изменений с другими репозиториями: забираются (pull) чужие наборы изменений и/или отдаются (push) собственные.

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

5.3.3 Начало работы

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

5.3.4 Создание репозитория и работа с файлами

В Mercurial все происходит внутри репозитория. Репозиторий проекта содержит все файлы, которые «относятся» к проекту, а также историю изменений этих файлов. Создать репозиторий можно тремя различными способами.

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

Рисунок 5.3.1 Создание репозитория

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

Рисунок 5.3.2 Расположение папки репозитория

Аналогично происходит создание репозитория непосредственно в окне TortoiseHg Workbench: последовательность Файл\Новое хранилище вызывает приведенное выше одноименное окно. В командной строке для создания репозитория в текущем каталоге используется команда hg init <имя хранилища>. Созданный репозиторий будет содержать каталог.hg.

Рисунок 5.3.3 Создание папки репозитория через командную строку

Если мы хотим добавить существующие файлы в репозиторий, мы копируем их внутрь рабочей директории, и с помощью команды hg add сообщаем Mercurial, что нужно начинать за ними следить. Добавим файл в репозиторий и создадим новую ревизию.

Рисунок 5.3.4 Добавление файла в репозиторий и создание новой ревизии

Убедимся, что Mercurial видит сохраненный файл. По команде status выводится состояние рабочей копии в сравнении с состоянием локального репозитория. Mercurial показывает, что видит файл example.txt, но этот файл пока не находится в системе контроля версий (символ «?» слева от имени файла). Для того, чтобы сказать Mercurial, что его необходимо версионировать, выполним hg add. Слева от имени файла появляется символ «А», который означает что файл readme.txt будет добавлен в систему контроля версий при следующем коммите (при создании новой ревизии), который выполняется командой hg commit.

В первый раз выполнение команды hg commit может пройти неудачно. Mercurial записывает ваше имя и адрес в каждую ревизию, чтобы вы или другие пользователи могли связаться с автором каждого изменения. Чтобы установить имя пользователя следует внести изменения в расположенный в каталоге.hg внутри рабочей директории файл hgrc. Первоначальное содержание этого файла должно выглядеть примерно так:

# This is a Mercurial configuration file.

username = Firstname Lastname [email protected]

Строка «» объявляет секцию конфигурационного файла. Вы можете прочитать «username =...» как «установить значение переменной username в секции ui». Секции продолжаются до начала новых секций. Пустые строки и строки, начинавшиеся с «#» игнорируются. Вы можете использовать любой текст в качестве значения username, так как эта информация предназначена для других людей, а не для интерпретации Mercurial"ом. В примере выше для этого использовалось распространенное соглашение: комбинация имени и адреса электронной почты.

Когда мы фиксируем изменения, Mercurial переводит нас в текстовый редактор, чтобы ввести комментарий, описывающий модификации, которые мы внесли в этом наборе изменений. Такое описание называется сообщением об изменениях (описанием изменений, описанием ревизии). Это будет записью для читателей о том, что мы сделали и почему, и будет выводиться при выполнении команды hg log после того, как мы закончим публикацию ревизии.

Редактор, который откроется при выполнении команды hg commit, будет содержать пустую строку и несколько строк, начинающихся с «HG:».

HG: Enter commit message. Lines beginning with "HG:" are removed.

HG: Leave message empty to abort commit.

HG: --

HG: user: user

HG: branch "default"

HG: changed example.txt

Mercurial игнорирует строки, начинающиеся с «HG:». Он использует их только для того, чтобы сообщить нам, изменения в каких файлах он запишет. Редактирование или удаление этих строк ни на что не повлияет. Если вы передумаете публиковать изменения во время редактирования комментария, просто выйдите из редактора без сохранения изменяемого файла. Это не вызовет изменений ни в репозитории, ни в рабочем каталоге.

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

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

Рисунок 5.3.5 Добавление файла в рабочий каталог

Перенесем файл в репозиторий и обновим окно, нажав на кнопку слева на панели инструментов. Добавим файл в систему контроля версий посредством соответствующей команды контекстного меню (аналог hg add).

Рисунок 5.3.6 Команда контекстного меню

Рисунок 5.3.7 Добавление файла

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

Рисунок 5.3.8 Графы изменений

Также фиксировать изменения можно командой Hg Commit в контекстном меню помещенного в репозиторий файла, не запуская Workbench.

Рисунок 5.3.9 Фиксация изменений

Команде hg log или hg diff здесь соответствует «Сравнить ревизии файла» (правый клик на имени файла).

Рисунок 5.3.10 Сравнение ревизий файла

В этом же окне можно вернуться к одной из предыдущих ревизий командой «Вернуться к ревизии…» или «Обратить изменения…» в основном окне. Продемонстрируем на примере, зафиксировав предварительно еще некоторые изменения файла example.txt. Выделенная красным строчка - обращенные изменения.

Рисунок 5.3.11 Отмена изменений

5.3.5 Создание копии репозитория

Хотя вы можете скопировать репозиторий как обычный каталог, лучше использовать встроенную команду Mercurial. Она называется hg clone, потому что создает идентичную копию существующего репозитория. Одно из преимуществ использования hg clone в том, что она позволяет клонировать репозитории по сети. Другим является то, что она запоминает, откуда мы его клонировали.

Каждый репозиторий Mercurial полон, самодостаточен и независим. Он содержит свою собственную копию файлов проекта и их историю. Клонированный репозиторий помнит, откуда он был клонирован, но не общается с тем репозиторием, да и ни с каким другим тоже, до тех пор пока вы ему не скажете. Следовательно, вы можете свободно экспериментировать с вашим репозиторием. Это безопасно, потому что ваш репозиторий -- «закрытая песочница», изменения в котором не повлияют ни на что, кроме него самого.

Создадим удаленную копию нашего хранилища (воспользуемся папкой Google Диск, которая сама по себе - облачный сервис), для чего выполним последовательность команд Файл\Клонировать хранилище в TortoiseHg Workbench. Результат представлен на следующем рисунке.

Рисунок 5.3.12 Создание удаленной копии хранилища

Mercurial позволяет передать изменения в другой репозиторий из репозитория, в котором мы в данный момент находимся. Добавим новую ревизию (под комментарием local change) в исходный репозиторий и выполним команду Хранилище\Синхронизация\Протолкнуть. Интерфейс рабочей среды позволяет выбрать только те ревизии, которые необходимо «протолкнуть». Обратим внимание, что в репозитории remote-vault была создана новая ветвь для полученной ревизии.

...

Подобные документы

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

презентация , добавлен 05.01.2014


Анализ методов и средств контроля доступа к файлам. Проблемы безопасности работы с файлами, средства контроля доступа ним. Идеология построения интерфейса, требования к архитектуре. Работа классов системы. Оценка себестоимости программного продукта.

дипломная работа , добавлен 21.12.2012


Анализ архитектуры ОС Windows 8. Сравнение с предыдущими версиями (интерфейс Modern UI, работа с учетными записями, модель безопасности, диспетчер задач, история файлов, восстановление системы, Storage Spaces). Особенности различных версий Windows 8.

курсовая работа , добавлен 25.01.2016


Этапы разработки автоматизированной системы приема и бронирования заказов столиков в заведениях. Анализ среды разработки Android Development Tools. Общая характеристика диаграммы компонентов IOS приложения. Рассмотрение системы контроля версий сервера.

курсовая работа , добавлен 14.05.2014


Графические интерфейсы и расширения для DOS. История развития операционной системы Microsoft Windows. Новшества ее современных версий: пользовательский интерфейс, языковая интеграция, системы защиты. Хронология развития и архитектура системы GNU/Linux.

реферат , добавлен 25.10.2010


Пакет средств разработки DirectX под Microsoft Windows, характеристика наборов COM-совместимых объектов в его составе. Ключевые особенности версий, шейдерные языки. Описание основных используемых функций. Исходный код программы, примеры ее работы.

курсовая работа , добавлен 16.02.2015


Windows как посредник пользователя и операционной системы, облегчая процесс общения между ними, история становления и развития ее первых версий. Функциональные особенности и отличия Windows 95/98/ME и Windows NT/2000/XP/Vista/7, их архитектурные решения.

презентация , добавлен 23.10.2013


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

дипломная работа , добавлен 19.01.2017


Понятие, сущность, структура и виды операционных систем. Характеристика операционной системы Windows XP, требования к ее установке, сравнительный анализ версий, особенности настройки, обновления версии, установки драйверов устройств и добавление новых.

реферат , добавлен 20.10.2009


Появление первых версий Windows, их графические интерфейсы и расширения для DOS. Семейства Windows 3.x и Windows 9.x, их особенности и основные функции. Эволюция технологии Plug and Play. Наиболее существенные улучшения в современных версиях Windows.

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

В каждой операции, производительность которой я измерял, Mercurial обладает большей производительностью, чем Subversion. Скорость больше в 2-6 раз, когда речь идет о локальном репозитории Subversion 1.4.3 (самый быстрый метод доступа). При более реалистичном варианте использования - сетевой репозиторий, Subversion находится в существенно худшем положении. В силу того, что команды Subversion должны взаимодействовать с сервером и при этом Subversion не имеет полезных средств репликации, производительность сервера и пропускная способность сети становятся узкими местами даже для некрупных проектов.

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

Subversion имеет широкую поддержку инструментария сторонних производителей. В этом отношении у Mercurial сейчас существенное отставание. Хотя разрыв сокращается, и некоторые GUI-утилиты для Mercurial превосходят свои аналоги для Subversion. Как и Mercurial, Subversion располагает отличным руководством пользователя.

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

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

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

1.6.2. Git

Git - распределенная система контроля версий, которая была разработана для управления исходным кодом ядра Linux. Как и в случае с Mercurial, на начальный дизайн системы оказал влияние Monotone.

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

Что касается производительности - Git очень быстр. В некоторых случаях он быстрее, чем Mercurial (по крайней мере под Linux), а в других быстрее оказывается Mercurial. Однако под Windows как производительность, так и общий уровень поддержки, во время написания этой книги у Git гораздо хуже, чем у Mercurial.

В то время как репозиторий Mercurial не требует операций по техническому обслуживанию, репозиторий Git требует частых ручных «перепаковок » собственных метаданных. Если этого не делать, производительность начинает падать, наряду с увеличением объёма занимаемого дискового пространства. Дисковый массив сервера, содержащего несколько Git репозиториев, по отношению к которым не выполняется строгое правило частой «перепаковки » , рано или поздно забивается под завязку, в результате чего процесс ежедневного резервного копирования легко может занимать более 24 часов. Только что «запакованный » репозиторий Git занимает немного меньше места, чем репозиторий Mercurial, но объём не перепакованного репозитория будет на несколько порядков больше.

Ядро Git написано на языке С. Многие команды Git реализованы в виде Shell скриптов или скриптов на языке Perl и уровень качества данных скриптов сильно разнится. Я встречал несколько установок, в которых скрипты тупо продолжали выполнение, несмотря на наличие фатальных ошибок.

Mercurial предоставляет возможность импорта истории версий из репозитория Git.

1.6.3. CVS

CVS, наверное, самая широко распространённая система контроля версий в мире. Благодаря почтенному возрасту, а также бардаку, царящему внутри, он очень слабо поддерживается уже много лет.

CVS основан на централизованной, клиент-серверной архитектуре. Он не выполняет группировку файловых изменений в атомарные коммиты, тем самым позволяя людям легко «сломать билд » : один человек может успешно внести часть изменений в репозиторий, а затем оказаться заблокированным из-за необходимости выполнения слияния. Это приведёт к ситуации, когда остальные участники увидят только часть из тех изменений, которые они должны были увидеть. Данная особенность также влияет на то, как вы будете работать с историей изменений. Если вы хотите получить все изменения, которые один из членов команды внёс для решения определённой задачи, вам необходимо вручную исследовать описания и дату внесения изменений, произведённых для каждого затрагиваемого файла (если вы вообще знаете, какие файлы были затронуты).

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

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

«

1.8. Краткая история контроля версий

Самая известная из старых утилит контроля версий - SCCS (Source Code Control System, система контроля исходного кода), которую написал Марк Рочкайнд (Marc Rochkind) из Bell Labs, в начале 70-х. SCCS оперировала отдельными файлами и требовала, чтобы каждый человек, работающий над проектом, имел доступ к общему рабочему пространству, существовавшему в единственном экземпляре. Только один человек мог одновременно редактировать файл в один момент времени; конфликты доступа к файлам разрешались блокировками. Обычной ситуацией было забывание снятия блокировки после редактирования, что запрещало доступ к файлу другим людям без помощи администратора.

Вальтер Тичи (Walter Tichy) разработал свободную альтернативу SCCS в начале 1980-х; он назвал свою программу RCS (Revision Control System, система контроля ревизий). Подобно SCCS, RCS требовала от разработчиков как работы в едином разделяемом рабочем пространстве, так и блокировки файлов для предотвращения одновременного изменения файлов разными людьми.

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

Брайан Берлинер (Brian Berliner) взял первоначальные скрипты Грюна и переписал их на Си, выпустив в 1989 году код, который впоследствии развился в современную версию CVS. CVS в дальнейшем приобрела возможность работать по сети, обретя клиент-серверную архитектуру. Архитектура CVS является централизованной: только на сервере есть копия истории проекта. Клиентские рабочие копии содержали только экземпляры файлов последней версии и небольшие метаданные для определения местонахождения сервера. Система CVS достигла небывалого успеха: вероятно, она является самой широко используемой системой контроля версий в мире.

В начале 1990-х годов Sun Microsystems разработала раннюю распределённую систему контроля версий, называвшуюся TeamWare. Каждая рабочая копия TeamWare содержала полную копию истории изменений проекта. Понятие центрального репозитория в TeamWare отсутствовало как таковое. (Подобно CVS, использовавшей RCS для хранения истории, TeamWare использовала SCCS.)

Шли 1990-ые, росла осведомлённость о нескольких проблемах CVS. Система записывает одновременные изменения нескольких файлов раздельно, а не группирует их в одну логически атомарную операцию. Способ управления файловой иерархией не очень хорош: нетрудно устроить в репозитории беспорядок, переименовывая файлы и каталоги. Более того, исходные коды CVS непросто понимать и поддерживать, что сделало практически непреодолимым «болевой порог » исправления этих архитектурных проблем.

В 2001 году Джим Бланди (Jim Blandy) и Карл Фогель (Karl Fogel) - два разработчика, прежде работавшие над CVS - начали проект по её замене таким средством, которое имело бы архитектуру получше и код почище. Результат - Subversion - не отошёл от централизованной клиент-серверной модели CVS, но добавил атомарные коммиты нескольких файлов, лучшее управление пространствами имён и другие возможности, которые сделали Subversion более удобным средством работы, нежели CVS. Со времени выхода первой версии Subversion быстро обретал популярность.

Более или менее одновременно, Грейдон Хоар (Graydon Hoare) начал работать над амбициозной системой контроля версий, которую назвал Monotone. Эта система не только устраняет множество проблем внутреннего устройства CVS и имеет распределённую архитектуру, но и идёт далее нескольких прежних (и последующих) систем контроля версий в некоторых своих нововведениях. Monotone использует криптографические хеши в качестве идентификаторов и имеет неотъемлемое представление о «доверии » коду из различных источников.

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

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

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

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

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

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

Многие системы управления версиями предоставляют ряд других возможностей:

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

Типичный порядок работы с системой

Каждая система управления версиями имеет свои специфические особенности в наборе команд, порядке работы пользователей и администрировании. Тем не менее, общий порядок работы для большинства VCS совершенно стереотипен. Здесь предполагается, что проект, каким бы он ни был, уже существует и на сервере размещён его репозиторий , к которому разработчик получает доступ.

Начало работы с проектом

Первым действием, которое должен выполнить разработчик, является извлечение рабочей копии проекта или той его части, с которой предстоит работать. Это действие выполняется с помощью команды извлечения версии (обычно checkout или clone ). Разработчик задаёт версию, которая должна быть скопирована, по умолчанию обычно копируется последняя (или выбранная администратором в качестве основной) версия.

По команде извлечения устанавливается соединение с сервером, и проект (или его часть - один из каталогов с подкаталогами) в виде дерева каталогов и файлов копируется на компьютер разработчика. Обычной практикой является дублирование рабочей копии: помимо основного каталога с проектом на локальный диск (либо в отдельный, специально выбранный каталог, либо в системные подкаталоги основного дерева проекта) дополнительно записывается ещё одна его копия. Работая с проектом, разработчик изменяет только файлы основной рабочей копии. Вторая локальная копия хранится в качестве эталона, позволяя в любой момент без обращения к серверу определить, какие изменения внесены в конкретный файл или проект в целом и от какой версии была «отпочкована» рабочая копия; как правило, любая попытка ручного изменения этой копии приводит к ошибкам в работе программного обеспечения VCS.

Ежедневный цикл работы

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

Обновление рабочей копии По мере внесения изменений в основную версию проекта рабочая копия на компьютере разработчика стареет: расхождение её с основной версией проекта увеличивается. Это повышает риск возникновения конфликтных изменений (см. ). Поэтому удобно поддерживать рабочую копию в состоянии, максимально близком к текущей основной версии, для чего разработчик выполняет операцию обновления рабочей копии (update ) насколько возможно часто (реальная частота обновлений определяется частотой внесения изменений, зависящей от активности разработки и числа разработчиков, а также временем, затрачиваемым на каждое обновление - если оно велико, разработчик вынужден ограничивать частоту обновлений, чтобы не терять время). Модификация проекта Разработчик модифицирует проект, изменяя входящие в него файлы в рабочей копии в соответствии с проектным заданием. Эта работа производится локально и не требует обращений к серверу VCS. Фиксация изменений Завершив очередной этап работы над заданием, разработчик фиксирует (commit ) свои изменения, передавая их на сервер (либо в основную ветвь, если работа над заданием полностью завершена, либо в отдельную ветвь разработки данного задания). VCS может требовать от разработчика перед фиксацией обязательно выполнить обновление рабочей копии. При наличии в системе поддержки отложенных изменений (shelving ) изменения могут быть переданы на сервер без фиксации. Если утверждённая политика работы в VCS это позволяет, то фиксация изменений может проводиться не ежедневно, а только по завершении работы над заданием; в этом случае до завершения работы все связанные с заданием изменения сохраняются только в локальной рабочей копии разработчика.

Ветвления

Делать мелкие исправления в проекте можно путём непосредственной правки рабочей копии и последующей фиксации изменений прямо в главной ветви (в стволе) на сервере. Однако при выполнении объёмных работ такой порядок становится неудобным: отсутствие фиксации промежуточных изменений на сервере не позволяет работать над чем-либо в групповом режиме, кроме того, повышается риск потери изменений при локальных авариях и теряется возможность анализа и возврата к предыдущим вариантам кода в пределах данной работы. Поэтому для таких изменений обычной практикой является создание ветвей (branch ), то есть «отпочковывание» от ствола в какой-то версии нового варианта проекта или его части, разработка в котором ведётся параллельно с изменениями в основной версии. Ветвь создаётся специальной командой. Рабочая копия ветви может быть создана заново обычным образом (командой извлечения рабочей копии, с указанием адреса или идентификатора ветви), либо путём переключения имеющейся рабочей копии на заданную ветвь.

Базовый рабочий цикл при использовании ветвей остаётся точно таким же, как и в общем случае: разработчик периодически обновляет рабочую копию (если с ветвью работает более одного человека) и фиксирует в ней свою ежедневную работу. Иногда ветвь разработки так и остаётся самостоятельной (когда изменения порождают новый вариант проекта, который далее развивается отдельно от основного), но чаще всего, когда работа, для которой создана ветвь, выполнена, ветвь реинтегрируется в ствол (основную ветвь). Это может делаться командой слияния (обычно merge ), либо путём создания патча (patch ), содержащего внесённые в ходе разработки ветви изменения и применения этого патча к текущей основной версии проекта.

Слияние версий

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

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

Во всех случаях ситуация принципиально одинакова и имеет следующие характерные черты:

1. Ранее была сделана копия дерева файлов и каталогов репозитория или его части.
2. Впоследствии и в оригинальное дерево, и в копию были независимо внесены некоторые изменения.
3. Требуется объединить изменения в оригинале и копии таким образом, чтобы не нарушить логическую связность проекта и не потерять данные.

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

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

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

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

При определении допустимости слияния изменений в пределах одного и того же текстового файла работает типовой механизм построчного сравнения текстов (примером его реализации является системная утилита GNU diff), который сравнивает объединяемые версии с базовой и строит список изменений, то есть добавленных, удалённых и заменённых наборов строк. Минимальной единицей данных для этого алгоритма является строка, даже самое малое отличие делает строки различными. С учётом того, что символы-разделители, в большинстве случаев, не несут смысловой нагрузки, механизм слияния может игнорировать эти символы при сравнении строк.

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

Конфликты и их разрешение

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

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

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

Блокировки

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

Массовое использование блокировок, когда все или большинство файлов в проекте являются блокируемыми и для любых изменений необходимо заблокировать соответствующий набор файлов, называется ещё стратегией «блокированного извлечения». Ранние системы управления версиями поддерживали исключительно эту стратегию, предотвращая таким способом появление конфликтов на корню. В современных VCS предпочтительным является использование неблокирующих извлечений, блокировки же считаются скорее неизбежным злом, которое нужно по возможности ограничивать. Недостатки использования блокировок очевидны:

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

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

Версии проекта, теги

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

Одни системы поддерживают версионность файлов . Это означает, что любой файл, появляющийся в проекте, получает собственный номер версии (обычно - номер 1, условной «нулевой» версией файла считается пустой файл с тем же именем). При каждой фиксации разработчиком изменений, затрагивающих файл, соответствующая часть фиксируемых изменений применяется к файлу и файл получает новый, обычно следующий по порядку, номер версии. Поскольку фиксации обычно затрагивают только часть файлов в репозитории, номера версий файлов, имеющиеся на один и тот же момент времени, со временем расходятся, и проект в целом (то есть весь набор файлов репозитория), фактически, никакого «номера версии» не имеет, поскольку состоит из множества файлов с различными номерами версий. Подобным образом работает, например, система управления версиями CVS.

Для других систем понятие «версия» относится не к отдельному файлу, а к репозиторию целиком. Вновь созданный пустой репозиторий имеет версию 1 или 0, любая фиксация изменений приводит к увеличению этого номера (то есть даже при изменении одного файла на один байт весь репозиторий считается изменённым и получает новый номер версии). Таким способом трактует номера версий, например, система Subversion. Номера версии отдельного файла здесь, фактически, не существует, условно можно считать таковым текущий номер версии репозитория (то есть считать, что при каждом изменении, внесённом в репозиторий, все его файлы меняют номер версии, даже те, которые не менялись). Иногда, говоря о «версии файла» в таких системах, имеют в виду ту версию репозитория, в которой файл был последний раз (до интересующего нас момента) изменён.

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

Тег (tag) - это символическая метка, которая может быть связана с определённой версией файла и/или каталога в репозитории. С помощью соответствующей команды всем или части файлов проекта, отвечающим определённым условиям (например, входящим в головную версию главной ветви проекта на определённый момент времени) может быть присвоена заданная метка. Таким образом можно идентифицировать версию проекта (версия «XX.XXX.XXX» - это набор версий файлов репозитория, имеющих тег «XX.XXX.XXX»), зафиксировав таким образом его состояние на некоторый желаемый момент. Как правило, система тегов достаточно гибкая и позволяет пометить одним тегом и не одновременные версии файлов и каталогов. Это позволяет собрать «версию проекта» любым произвольным образом. С точки зрения пользователя системы пометка тегами может выглядеть по-разному. В некоторых системах она изображается именно как пометка (тег можно создать, применить к определённым версиям файлов и каталогов, снять). В других системах (например, Subversion) тег представляет собой просто отдельный каталог на файловом дереве репозитория, куда из ствола и ветвей проекта с помощью команды копирования делаются копии нужных версий файлов. Так что визуально тег - это просто вынесенная в отдельный каталог копия определённых версий файлов репозитория. По соглашению в дерево каталогов, соответствующее тегу, запрещена фиксация изменений (то есть версия проекта, представляемая тегом, является неизменной).

Базовые принципы разработки ПО в VCS

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

1. Любые рабочие, тестовые или демонстрационные версии проекта собираются только из репозитория системы. «Персональные» сборки, включающие ещё незафиксированные изменения, могут делать только разработчики для целей промежуточного тестирования. Таким образом, гарантируется, что репозиторий содержит всё необходимое для создания рабочей версии проекта.
2. Текущая версия главной ветви всегда корректна. Не допускается фиксация в главной ветви неполных или не прошедших хотя бы предварительное тестирование изменений. В любой момент сборка проекта, проведённая из текущей версии, должна быть успешной.
3. Любое значимое изменение должно оформляться как отдельная ветвь. Промежуточные результаты работы разработчика фиксируются в эту ветвь. После завершения работы над изменением ветвь объединяется со стволом. Исключения допускаются только для мелких изменений, работа над которыми ведётся одним разработчиком в течение не более чем одного рабочего дня.
4. Версии проекта помечаются тегами. Выделенная и помеченная тегом версия более никогда не изменяется.

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

amend Внести изменения, не создавая новой версии - обычно когда разработчик ошибочно зафиксировал (commit ) версию, но не залил (push ) её на сервер. blame Понять, кто внёс изменение. branch Ветвь - направление разработки, независимое от других. Ветвь представляет собой копию части (как правило, одного каталога) хранилища, в которую можно вносить свои изменения, не влияющие на другие ветви. Документы в разных ветвях имеют одинаковую историю до точки ветвления и разные - после неё. changeset, changelist, activity Набор изменений. Представляет собой поименованный набор правок, сделанных в локальной копии для какой-то общей цели. В системах, поддерживающих наборы правок, разработчик может объединять локальные правки в группы и выполнять фиксацию логически связанных изменений одной командой, указывая требуемый набор правок в качестве параметра. При этом прочие правки останутся незафиксированными. Типичный пример: ведётся работа над добавлением новой функциональности, а в этот момент обнаруживается критическая ошибка, которую необходимо немедленно. Разработчик создаёт набор изменений для уже сделанной работы и новый - для исправлений. По завершении исправления ошибки отдаётся команда фиксации только второго набора правок. check-in, commit, submit Создание новой версии, фиксация изменений. В некоторых СУВ (Subversion ) - новая версия автоматически переносится в хранилище документов. check-out, clone Извлечение документа из хранилища и создание рабочей копии. conflict Конфликт - ситуация, когда несколько пользователей сделали изменения одного и того же участка документа. Конфликт обнаруживается, когда один пользователь зафиксировал свои изменения, а второй пытается зафиксировать и система сама не может корректно слить конфликтующие изменения. Поскольку программа может быть недостаточно разумна для того, чтобы определить, какое изменение является «корректным», второму пользователю нужно самому разрешить конфликт (resolve ). graft, backport, cherry-picking, transplant Использовать встроенный в СУВ алгоритм слияния, чтобы перенести отдельные изменения в другую ветвь, не сливая их. Например, исправили ошибку в экспериментальной ветви - вносим эти же изменения в стабильный ствол. head Основная версия - самая свежая версия для ветви/ствола, находящаяся в хранилище. Сколько ветвей, столько основных версий. merge, integration Слияние - объединение независимых изменений в единую версию документа. Осуществляется, когда два человека изменили один и тот же файл или при переносе изменений из одной ветки в другую. pull, update Получить новые версии из хранилища. В некоторых СУВ (Subversion ) - происходит и pull , и switch , то есть загружаются изменения, а потом рабочая копия доводится до последнего состояния. Будьте внимательны , понятие update двусмысленно и в Subversion и Mercurial значит разное. push Залить новые версии в хранилище. Многие распределённые СУВ (Git , Mercurial ) предполагают, что commit надо давать каждый раз, когда программист выполнил какую-то законченную функцию. А залить - когда есть интернет и другие хотят ваши изменения. Commit обычно не требует ввода имени и пароля, а push - требует. rebase Использовать встроенный в СУВ алгоритм слияния, чтобы перенести точку ветвления (версию, от которой начинается ветвь) на более позднюю версию ствола. Чаще всего применяется в таком сценарии: Борис внёс изменения и обнаруживает, что не может залить (push ) их, поскольку Анна ранее изменила совершенно другое место кода. Можно просто слить их (merge ). Но дерево будет линейным и более читабельным, если отказаться от своей редакции, но внести те же изменения в редакцию Анны - это и есть rebase . Если Анна и Борис работают над одним и тем же местом кода, мешая друг другу и разрешая конфликты вручную, rebase не рекомендуется. repository, depot Хранилище документов - место, где система управления версиями хранит все документы вместе с историей их изменения и другой служебной информацией. revision Версия документа. Системы управления версиями различают версии по номерам, которые назначаются автоматически. shelving Откладывание изменений. Предоставляемая некоторыми системами возможность создать набор изменений (changeset) и сохранить его на сервере без фиксации (commit’а). Отложенный набор изменений доступен на чтение другим участникам проекта, но до специальной команды не входит в основную ветвь. Поддержка откладывания изменений даёт возможность пользователям сохранять незавершённые работы на сервере, не создавая для этого отдельных ветвей. strip Удалить целую ветвь из хранилища. tag, label Метка, которую можно присвоить определённой версии документа. Метка представляет собой символическое имя для группы документов, причём метка описывает не только набор имён файлов, но и версию каждого файла. Версии включённых в метку документов могут принадлежать разным моментам времени. trunk, mainline, master Ствол - основная ветвь разработки проекта. Политика работы со стволом может отличаться от проекта к проекту, но в целом она такова: большинство изменений вносится в ствол; если требуется серьёзное изменение, способное привести к нестабильности, создаётся ветвь , которая сливается со стволом, когда нововведение будет в достаточной мере испытано; перед выпуском очередной версии создаётся ветвь для последующего выпуска, в которую вносятся только исправления. update, sync, switch Синхронизация рабочей копии до некоторого заданного состояния хранилища. Чаще всего это действие означает обновление рабочей копии до самого свежего состояния хранилища. Однако при необходимости можно синхронизировать рабочую копию и к более старому состоянию, чем текущее. working copy Рабочая (локальная) копия документов.

См. также

• Сравнение систем управления версиями (Software Configuration Management), Бен Коллинз-Сассман (создатель Subversion) о распределённых системах управления версиями.
• (англ.) сравнение систем управления версиями с точки зрения завершённости процесса разработки ПО .

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

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

Вернуться в

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

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

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

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