Системы контроля версий

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

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

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

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

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

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

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

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

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

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

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

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

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

2013

Реферат

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

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

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

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

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

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

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



Содержание

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

Введение

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

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

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

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

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

3.3 Ветвления

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

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

3.6 Блокировки

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

4. Типы

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

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

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

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

5.1 GIT

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

5.1.2 Концепция

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

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

5.2 TortoiseSVN

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

5.2.2 Установка

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

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

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

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

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

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

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

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

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

5.3 Mercurial

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

5.3.2 Концепция

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

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

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

Заключение

Приложение А

Приложение Б

Приложение В



Введение

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

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

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

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

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

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

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

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

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

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

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

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. Типы

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 your_email@whatever.com

Созданный репозиторий будет содержать директорию.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 init

- 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.

[ui]

username = Firstname Lastname email.address@example.net

Строка «[ui]» объявляет секцию конфигурационного файла. Вы можете прочитать «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 была создана новая ветвь для полученной ревизии.

...