Краткие теоретические сведения

Fossil — распределённая система управления версиями. Вся функциональность реализована в одном исполняемом файле (fossil.exe). Размер файла колеблется для различных сборок от двух мегабайт до четырех. Процедура установки не требуется, достаточно просто скопировать файл в папку на компьютере, доступную через переменную $PATH.

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

Также Fossil не требует никаких внешних зависимостей: не нужны CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL, SQLite, patch, или какие-либо подобные приложения для эффективного использования Fossil.

Ход работы

Установка

Для установки системы контроля версий Fossil необходимо перейти на http://www.fossil-scm.org/download.html и скачать пакет, соответствующий вашей операционной системе. Fossil совместим с операционными системами Windows, Linux, Mac, OpenBSD. После скачивания архива, распаковываем находящийся там исполняемый файл в каталог, доступный через переменную $PATH. Теперь система готова к работе.

Рисунок 1 – Загрузка Fossil.

При рассмотрении программы Fossil, предполагается что установлена операционная система Windows.

Для того чтобы запустить Fossil, необходимо вызвать командную строку. Для вызова командной сроки нажмите одновременно комбинацию клавиш «win+r», введите в поле команду «cmd» и нажмите «ok» (рис.2).

Откроется окно командной строки (рис.3).

 

Рисунок 2 – Вызов командной строки.

Рисунок 3 – Командная строка.

Для того чтобы начать работы с Fossil, введите в командной строке следующую команду «fossil», теперь система контроля версий запущена, и можно преступить к изучению её возможностей.

Рисунок 4 – Запуск Fossil.

2. Создание и настройка репозитория

Начиная работу с Fossil, будем считать, что все репозитории будут храниться в отдельном каталоге c:\fossil, следует заметить, что это не обязательное условие, с так же можно размещать репозитории непосредственно рядом с файлами, которые мы отдаем под управление Fossil.

Рисунок 5 – Место расположения каталога.

Создадим новый репозиторий test в каталоге fossil, для этого введите команду в командной строке «fossil new c:\fossil\test.fossil».

Рисунок 6 – Создание нового репозитория.

Fossil создаст файл test.fossil и сообщит нам имя администратора (обычно это имя пользователя, под которым вы вошли в ОС) и пароль.

 

 

Рисунок 7 – Результат команды.

Откроем нужный репозиторий, для этого введите команду в командной строке «fossil open c:\fossil\test.fossil».

Рисунок 8 – Результат обработки команды «fossil open c:\fossil\test.fossil».

Команда открытия «fossil open» создает в текущем каталоге служебный файл базы данных, его имя может зависеть от версии Fossil и от ОС — под Windows это _FOSSIL_. В этом файле хранится информация об открытом репозитории и отслеживаются изменения в файлах. Обратите внимание, что перед тем, как открыть репозиторий, необходимо перейти в каталог, родительский по отношению к рабочему. Это важно: репозиторий должен быть открыт или в рабочем каталоге, или в одном из родительских (на любом уровне дерева), иначе Fossil откажется добавлять файлы из рабочего каталога в репозиторий.

Рисунок 9 – Отображение служебного файла при открытии репозитория.

Для того чтобы перейди в родительский каталог необходимо последовательно ввести команды «c:», «cd\fossil».

 

 

Команды для добавления файла в репозиторий введите команду «fossil add name_file».

Рисунок 11 – Добавление файла test.txt.

Для того чтобы не добавлять файлы из каталога по одному существует команда «fossil add». В результате все файлы в каталоге добавятся в репозиторий.

Рисунок 12 – Добавление всех файлов в репозиторий.

Команды для удаления файла в репозиторий введите команду «fossil rm name_file».

Рисунок 13 – Удаление файла test.txt.

Для удаления всех файлов из репозитория, достаточно выполнить «fossil rm».

 

 

Рисунок 14 – Удаление всех файлов из репозитория.

Для изменяя имени файла используете команду «fossil mv old_name new_name» или

«fossil rename old_name new_name»

 

Рисунок 15 – Изменение имени с помощью команды «fossil mv old_name new_name».

Рисунок 16 – Изменение имени с помощью команды «fossil rename old_name

new_name».

Если необходимо, чтобы некоторые типы файлов не вносились в репозиторий, с помощью команды «fossil setting ignore-globe ‘type_of_file(s)» можно запретить в носить в репозиторий файлы с указанными расширениями, при чем «-globe» указывает, что любой репозиторий на данной машине не будет содержать файлы с запрещёнными расширениями. Команда «fossil setting ignore ‘type_of_file(s)», имеет тоже назначение, но запрет действует в рамках текущего репозитория.

 

 

Рисунок 17 – Запрет на определенные типы файлов для всех репозиториев.

 

 

Рисунок 18 – Запрет на определенные типы файлов для текущего репозитория.

Теперь, когда репозиторий открыт и файлы в него добавлены, т.е., поставлены под управление Fossil, можно, собственно, продолжить работу над проектом. Пишем программы, статьи, книги, при каждом важном изменении отправляем его в репозиторий — делаем commit, сопровождая его осмысленным комментарием. Для выполнения commit необходимо выполнить команду «fossil commit –m “Name_of_commit”».

Рисунок 19 – Создание commit.

Проверить текущее состояние репозитория можно командой «fossil status».

 

Рисунок 20 – Проверка состояния репозитория.

Теперь рассмотрим перенос репозитория на другой компьютер — с работы на домашний, или на ноутбук, который мы берем с собой в командировку. Для этого существует команда «fossile clone out_place_name in_place_name», которая позволяет перенести репозиторий с одного компьютера на другой, на съемный носитель, в другой раздел диска или локальный сервер.

 

Рисунок 21 – Копирование репозитория.

 

 

Рисунок 22 – Результат копирование репозитория.

Теперь откроем репозиторий на диске «c:», как было показано раньше (рис. 8), и изменим файл, сделаем commit и теперь нам нужно отправить изменения в другой репозиторий, к которому у нас есть доступ, для примера «d:\fossil\test.fossil» и выполним команду «fossil pull». В результате все изменения на диске «с:» будут перенесены в репозиторий на диске «d:».

Рисунок 23 – Результат пересылки репозитория.

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

Создадим новую ветку в репозитории с помощью команды «fossil branch new name_branch current_branch».

Рисунок 24 – Создание новой ветки.

trunk — это та ветвь, от которой производится ответвление, trunk — это название главного «ствола» любого проекта в рамках системы контроля версий Fossil. Если теперь выполним команду «fossil branch list» — вывод списка существующих ветвей, то увидим, что теперь 2 ветки — trunk и ver_2, причем знаком "*" помечена ветка trunk — это значит, что именно она — текущая. Создание новой ветки не изменяет статус рабочих файлов — текущей считается все еще в старая ветка trunk, это можно проверить и командой «fossil status». Чтобы перейти в новую ветку, выполняем команду «fossil cheakout ver_2».

Рисунок 25 – Список существующих веток.

 

Рисунок 26 – Смена ветки и проверка текущей ветки.

Теперь все наши последующие изменения будут относиться к ветке ver_2. Если нам понадобится произвести в ветке trunk те изменения, которые произошли в ver_2, переходим в trunk и производим объединение рис. 27 – 28.

Рисунок 27 – Переход на ветку trunk и проверка текущей ветки.

 

Рисунок 28 – Объединение текущей ветки и ветки «ver_2».

Порядок выполнения работы:

1. Установить Fossil на свой компьютер

2. Создать репозиторий.

3. Выполнить задание в соответствии со своим вариантом, приведенным в таблице 1.

4. Составить отчет и защитить у преподавателя.

5.

Ответить на контрольные вопросы. Таблица 1 – Задания для выполнения работы.

Контрольные вопросы:

1. Что такое Fossil?

2. В чем его преимущество?

3. С помощью каких команд можно создавать и удалять файлы из репозиториев?

4. В чем смысл веток?

5. Что указывает на то, что данный репозиторий используется?

6. Что происходит при вызове команды «pull»?

7. В чем разница между командами «fossil add name_file» и «fossil add»? Для чего они предназначены?

8. В чем разница между командами «fossil mv old_name_file new_file_name» и

«fossil rename old_name_file new_file_name»? Для чего они предназначены?

9. На какие носители возможно копирование репозитория? С помощью какой команды выполняется копирование?

10. С помощью какой команды можно просмотреть историю изменений репозитория?

Лабораторная работа № 6 "GIT"

 

 

Введение

При работе над программными продуктами часто возникают проблемы с:

 

1. отслеживанием всех изменений (даты, времени, авторства, замечаний) во всех файлах с исходным кодом проекта;

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

3. внесение изменений в файлы проекта в соответствии с изменениями, сделанными на компьютере пользователя, полуавтоматическое разрешение возникающих конфликтов редактирования;

4. контроль доступа к исходным текстам и информация о них;

5. хранение пересекающихся и непересекающихся версий и ветвей разрабатываемых файлов.

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

1. Задание

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

• создание проекта и репозитория;

• проверка состояния репозитория;

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

• история версий;

• создание алиасов;

• перемещение по версиям;

• тегирование;

• клонирование репозиториев;

• отмена ошибочных изменений, коммитов;

• ветвление и разрешение конфликтов при ветвлении;

• создание чистого репозитория.

2. Ход работы

Подготовка к работе с Git

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

Для этого в окне Git необходимо выполнить следующие команды:

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

git config --global user.email "your_email@whatever.com"

Пример выполнения команд представлен на рисунке 2.1.

 

Рисунок 2.1 – Настройка имени и электронной почты.

 

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

Для этого необходимо выполнить следующие команды:

git config --global core.autocrlf true git config --global core.safecrlf true

Пример выполнения команд представлен на рисунке 2.2.

Рисунок 2.2 – Настройка параметров окончания строк.

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

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

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

Для этого необходимо выполнить следующие команды:

mkdir «your initials» cd «your initials»

Пример выполнения команд представлен на рисунке 2.3.

Рисунок 2.3 – Создание каталога.

 

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

touch new_project.cs

Пример выполнения команды представлен на рисунке 2.4.

Рисунок 2.4 – Создание файла

6

 

Пример созданного файла представлен на рисунке 2.5.

Рисунок 2.5 – Вновь созданный файл.

 

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

git init

Результат выполнения команды изображен на рисунке 2.6

Рисунок 2.6 – Результат создания репозитория.

 

Чтобы система начала контроль версий файлов, необходимо добавить их в репозиторий. То есть, следующим шагом необходимо добавить, например, файл «new_project.cs» в созданный репозиторий и добавить коммит, говорящий

7

 

о том, что текущая версия файла не содержит никакого программного кода, т.е. файл пустой. Для этого нужно выполнить следующие команды:

git add new_project.cs

git commit -m "Just empty file"

Результат выполнения команд представлен на рисунке 2.7.

Рисунок 2.7 – Результат добавления первого коммита.

 

Проверка состояния репозитория

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

git status

Результат выполнения команды представлен на рисунке 2.8.

Рисунок 2.8 – Проверка состояния репозитория.

8

 

Индексация изменений

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

 

Рисунок 2.9 – Результат проверки состояния репозитория, после изменения исходного файла.

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

 

Рисунок 2.10 – Проверка состояние репозитория и добавление коммита.

9

 

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

 

Рисунок 2.11 – Очередная проверка состояния репозитория.

 

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

Следующим шагом необходимо добавить коммит к проиндексированной версии, проиндексировать последнюю версию и добавить коммит к ней.

10

 

История версий

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

git log

Результат выполнения команды представлен на рисунке 2.12

Рисунок 2.12 – История проекта.

 

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

 

Рисунок 2.13 – История проекта в режиме «одной строки».

11

 

Для ещё более удобного вывода истории можно использовать различные способы форматирования. Пример одного из них представлен на рисунке 2.14

Рисунок 2.14 – Пример форматированной истории.

 

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

Алиасы

Алиас – псевдоним/сокращение команды.

Примеры использования алиасов представлены на рисунке 2.15.

Рисунок 2.15 – Использование алиасов.

12

 

Возврат к прошлым версиям

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

git checkout <hash>

Результат выполнения команды представлен на рисунке 2.16.

Рисунок 2.16 – Возврат к прошлым версиям.

 

В случае необходимости возврата к последней версии файла, достаточно дать аналогичную команду. Результат представлен на рисунке 2.17.

 

Рисунок 2.17 – Пример возврата к последней версии файла.

13

 

Тегирование версий

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

git tag <some_tag>

Пример выполнения команды представлен на рисунке 2.18.

Рисунок 2.18 – Пример использования тегов в отслеживании версий.

14

 

Отмена локальных изменений

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

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

Рисунок 2.19 – Пример отмены изменений.

 

Если же случилось так, что файл с ошибками был проиндексирован, но к нему не добавлен коммит, и его необходимо откатить, нужно выполнить команду:

git reset HEAD <file’s_name>

Пример выполнения подобной операции приведен на рисунке 2.20.

15

Рисунок 2.20 – Пример отмены проиндексированных изменений.

 

Если же случилось так, что файл с ошибками был проиндексирован, и к нему добавлен коммит, и его необходимо откатить, нужно выполнить команду:

git revert HEAD

Пример выполнения команды представлен на рисунке 2.21

16

Рисунок 2.21 – Пример отмены неправильного коммита.

 

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

17

 

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

 

Рисунок 2.22 – Пример удаления.

 

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

18

 

Рисунок 2.23 – Исправление коммита.

19

 

Создание ветки

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

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

Рисунок 2.24 – Создание ветки the_first_branch.

 

Пример работы с ветками изображен на рисунках 2.25, 2.26.

20

Рисунок 2.25 – Работа с ветками.

21

Рисунок 2.26 – Работа с ветками.

22

 

Слияние веток

Пример слияния веток изображен на рисунке 2.27.

Рисунок 2.27 – Слияние веток.

23

 

Конфликт

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

 

Рисунок 2.28 – Конфликт веток.

 

Кроме того, Git делает необходимые подсказки в самих файлах. Пример этого представлен на рисунке 2.29.

24

Рисунок 2.29 – Комментарии Git относительно места конфликта.

 

Разрешение конфликтов

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

Пример разрешения конфликта изображен на рисунке 2.30.

 

Рисунок 2.30 – Разрешенный конфликт.

25

 

Создание чистого репозитория

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

Пример создания чистого репозитория и работы с ним изображен на рисунках 2.31 и 2.32.

 

Рисунок 2.31 – Создание репозитория clean_repo.

26

 

Рисунок 2.32 – Работа с удаленным репозиторием.

27

 

Варианты

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

 

1 Вариант: Провести тегирование каждой версии (не менее 9 версий), задать дополнительно 2-3 алиаса и использовать их.

2 Вариант: Использовать в работе 2 разных файла, создать 4 конфликта и разрешить их.

3 Вариант: Исправить в ходе работы не менее 5 коммитов, задать дополнительно 3-4 алиаса и использовать их.

4 Вариант: Создать 3 разных конфликта и разрешить их.

5 Вариант: Использовать в работе 2 разных файла, и количество версий каждого файла не должно быть меньше 5.

6 Вариант: Использовать в работе 3 разных файла, и количество версий каждого файла не должно быть меньше 3.

7 Вариант: Использовать в работе 2 разных файла, для одного из них использовать 3 различные ветки.

8 Вариант: Использовать в работе 3 разных файла, для одного из них использовать 2 различные ветки.

9 Вариант: Использовать в работе 4 разных файла

10 Вариант: Использовать 3 ветки, создать 2 конфликта и разрешить их.

28

 

Вопросы к лабораторной работе

1) В чем заключается удобство использования системы контроля версий Git?

2) Как изменить формат выводимой истории версий?

3) Как сократить время набора команд в системе Git?

4) Если необходимо выделить в истории группы версий, с определенными изменениями, как удобнее всего это сделать?

5) Что такое тегирование, и для чего его целесообразно использовать?

6) Как можно исправить коммит, если он оказался неверным?

7) Для чего используется ветвление?

8) В каком случае необходимо исправлять файлы, при слиянии веток?

9) Что такое алиасы? Для чего они применяются?

10) Что такое режим «одной строки»?

Лабораторная работа №7