трпп_1. Абдусалямова СК ИНБО0220 ПР1 ТРПП. Отчет по практической работе по дисциплине Технология разработки программных приложений

• Название: Отчет по практической работе по дисциплине Технология разработки программных приложений
• Анкор: трпп_1
• Дата: 27.02.2023
• Размер: 2.38 Mb.
• Имя файла: Абдусалямова СК ИНБО0220 ПР1 ТРПП.docx
• Тип: Отчет; #958164

МИНОБРНАУКИ РОССИИ

Федеральное государственное бюджетное образовательное учреждение высшего образования «МИРЭА  Российский технологический университет» РТУ МИРЭА

Институт информационных технологий (ИИТ)

Кафедра практической и прикладной информатики (ППИ)

ОТЧЕТ ПО ПРАКТИЧЕСКОЙ РАБОТЕ

по дисциплине «Технология разработки программных приложений»

Практическое занятие № 1

Студент группы ИНБО-01-17	ИНБО-02-20, Абдусалямова С.К.	(подпись)
Преподаватель	Жматов Д. В.	(подпись)
Отчет представлен	«___»________2022г.

Москва 2022 г.

СОДЕРЖАНИЕ

Часть 1. Основные команды git 3

Часть 2. Системы управления репозиториями 12

Ответы на контрольные вопросы 27

Вывод 27

Список использованных источников и литературы 28

Часть 1. Основные команды git

Задание

1. 
   Установите и настройте клиент git на своей рабочей станции.
   
2. 
   Создайте локальный репозиторий и добавьте в него несколько файлов.
   
3. 
   Внесите изменения в один из файлов.
   
4. 
   Проиндексируйте изменения и проверьте состояние.
   
5. 
   Сделайте коммит того, что было проиндексировано в репозиторий. Добавьте к коммиту комментарий.
   
6. 
   Измените еще один файл. Добавьте это изменение в индекс git. Измените файл еще раз. Проверьте состояние и произведите коммит проиндексированного изменения. Теперь добавьте второе изменение в индекс, а затем проверьте состояние с помощью команды git status. Сделайте коммит второго изменения.
   
7. 
   Просмотрите историю коммитов с помощью команды git log. Ознакомьтесь с параметрами команды и используйте некоторые из них для различного формата отображения истории коммитов.
   
8. 
   Верните рабочий каталог к одному из предыдущих состояний.
   
9. 
   Изучите, как создавать теги для коммитов для использования в будущем.
   
10. 
    Отмените некоторые изменения в рабочем каталоге (до и после индексирования).
    
11. 
    Отмените один из коммитов в локальном репозитории.
    

Ход работы

Перед работой в Git, его необходимо установить, что я и сделала. Чтобы проверить корректность установки, необходимо ввести в командную строку «git version» и, если программа корректно отображается в системе, отобразится ответ – версия установленной программы (Рисунок 1).



Рисунок 1 – Результат установки Git

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

git config --global user.name "Abdusalyamova S"

git config --global user.email "[e-mail]"

git config --global core.autocrlf true

git config --global core.safecrlf warn

git config --global core.quotepath off

Чтобы проверить верность введенных команд, напишем:

git config –list

Командная строка выведет (Рисунок 2):



Рисунок 2 – Базовые настройки Git

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

cd Documents

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

mkdir repositorii

Перейдем в созданную папку с помощью команды

cd repositorii

Создаем файл с расширением .html с помощью команды

touch proekt.html

Результат вышеперечисленных команд показан на рисунке 3.



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

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

git init

git add proekt.html

git commit -m “Первый коммит”

Консоль выведет уведомление о созданном коммите (Рисунок 4)



Рисунок 4 – Первый коммит

Поскольку файл был изменен с помощью команды nano в одноименном редакторе, в коммите указано «1 добавление в файл» («1 insertion»).

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

git status

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



Рисунок 5 – Статус репозитория

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

Изменяем файл proekt.html и снова смотрим состояние (Рисунок 6).


Рисунок 6 – Состояние после изменения файла

Git распознал, что файл был изменен, но эти изменения не зафиксированы в репозитории. Чтобы исправить ситуацию, проводим индексацию изменений. Добавляем файл и смотрим статус (Рисунок 7).

Проводим индексацию изменений и смотрим статус с помощью команд:

git add proekt.html

git status



Рисунок 7 – Индексация изменений

Изменения файла proekt.html были успешно проиндексированы. Однако, до сих пор изменения не прокомментированы.

Создадим файлы first.html, second.html, third.html, и теперь будем добавлять их для коммита поочерёдно.

Введём сначала команды:

git add first.html

git add second.html

git commit -m "Changes for first and second"

Затем:

git add third.html

git commit -m "Unrelated change to third"

Таким образом мы разделили индексации и коммиты.

Вносим изменение в файл proekt.html, добавляем его, затем опять изменяем и смотрим статус (Рисунок 8).



Рисунок 8 – Статус после двух изменений файла

Производим коммит и проверяем статус с помощью:

git commit -m "Изменили файл второй раз"

git status

Результат показан на рисунке 9.



Рисунок 9 – Статус после коммита

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

git add

git status

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



Рисунок 10 – Вывод статуса после добавления всех элементов

Просмотрим историю коммитов.

Для просмотра истории коммитов используется команда:

git log

Результат выполнения (Рисунок 11):



Рисунок 11 – История коммитов

Попробуем вывести историю следующей командой (Рисунок 12):

git log --pretty=oneline --max-count=2



Рисунок 12 – История двух последних коммитов

Благодаря данной команде у нас выводится 2 последних коммита.

Для получение старой версии нашего каталога необходимо узнать для начала хэши, для этого воспользуемся командой, где %h - укороченный хэш коммита, %d — дополнения коммита («головы» веток или теги), %ad — дата коммита, %s — комментарий, %an — имя автора, --graph — отображает дерево коммитов в виде ASCII-графика, --date=short — сохраняет формат даты коротким (Рисунок 13):

git log --pretty=format:"%h %ad | %s%d [%an]" --graph --date=short



Рисунок 13 – Вывод команды

Чтобы вернутся к первой версии репозитория, воспользуемся командой:

git checkout 32683ес

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



Рисунок 14 – Возврат к первой версии

Содержимое файла proekt.html вернулось к первоначальному состоянию. Вернемся в нынешнее последнее состояние и проверим, что находится в файле с помощью команд (Рисунок 15):

git checkout master

cat proekt.html

\

Рисунок 15 – Возврат к нынешней версии
Чтобы добавить нынешней версии тег v1, воспользуемся командой:

git tag v1

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

Рассмотрим отмену локальных изменений до индексации. Вносим изменения в файл и выводим его содержимое (Рисунок 16).



Рисунок 16 – Новые изменения файла

Возвращаемся к прошлой версии файла, смотрим статус, выводим содержимое файла:

git checkout proekt.html

git status

cat proekt.html

Проверим результаты (Рисунок 17):



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

Содержимое файла вернулось к исходному состоянию.

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

git add proekt.html

git status



Рисунок 18 – Проиндексированное изменение

Затем отменяем индексацию, переходим на просмотр файла и убеждаемся в отсутствии изменений (Рисунок 19):

git reset HEAD proekt.html

git checkout proekt.html

git status



Рисунок 19 – Отмена индексации

Рассмотрим отмену коммита. Опять же вносим изменения в файл. Проводим коммит, а затем отменяем его с помощью команды (Рисунок 20):

git revert HEAD

Убедимся в отмене коммита с помощью истории изменений.



Рисунок 20 – Проверка отмены индексации

Часть 2. Системы управления репозиториями

Задание

1. 
   Создайте аккаунты на GitHub.
   
2. 
   Создайте репозиторий согласно варианту.
   
3. 
   Создайте новый локальный репозиторий с несколькими файлами на рабочей станции и загрузите его содержимое на GitHub.
   
4. 
   Чтобы избежать ввода логина и пароля, создайте SSH-ключ для авторизации.
   
5. 
   Создайте в репозитории новую ветку. Произведите в ней несколько изменений и слейте с веткой master.
   
6. 
   Выполните цепочку действий в репозитории, согласно варианту
   

Вариант 4

1. 
   Клонируйте непустой удаленный репозиторий на локальную машину
   
2. 
   Создайте новую ветку и выведите список всех веток
   
3. 
   Произведите 3 коммита в новой ветке в разные файлы
   
4. 
   Выгрузите изменения в удаленный репозиторий
   
5. 
   Откатите в новой ветке предпоследний коммит (в том числе в удаленном репозитории)
   
6. 
   Выведите в консоли различия между веткой master и новой веткой
   
7. 
   Слейте новую ветку с master при помощи merge
   

Ход работы

Первым делом надо завести аккаунт на GitHub. У меня уже имеется таковой. Он представлен на рисунке 21.



Рисунок 21 – Мой аккаунт на GitHub

Чтобы работать со своего компьютера с GitHub и иметь доступ к проектам без постоянного проекта нам потребуются SHH-ключи. Проверка показала, что на моём устройстве они отсутствуют. Поэтому я создала нужную директорию и сгенерировала новый ключ с помощью команд:

cd

mkdir .ssh

cd .ssh

ssh-keygen -t rsa -b 4096 -C "[e-mail]"

После чего в консоль выведется информация, показанная на рисунке 22.


Рисунок 22 – Создание нового SSH-ключа

Добавляем ключ в ssh-agent, проверяем доступность ключа и связываем локальный репозиторий с удалённым с помощью команд:

ssh-agent

eval "$(ssh-agent -s)"

ssh-add /.ssh/id_rsa

cat /.ssh/id_rsa.pub

В итоге выведется такой ключ (Рисунок 23):



Рисунок 23 – SSH-ключ

Копируем полученный ключ и добавляем его в профиль на GitHub. Для этого создаём на профиле новый ключ и вставляем туда скопированный (Рисунок 24).



Рисунок 24 – Добавление нового ключа на GitHub

Теперь создаём новую директорию, заполняем файлами и после инициализируем новый локальный репозиторий (Рисунок 25), воспользовавшись следующими командами:

mkdir repo2

cd repo2

touch readme.txt

touch file.html

git init



Рисунок 25 – Создание нового локального репозитория

Связываем локальный и удалённый репозитории. Для этого в своём аккаунте на GitHub создаём новый репозиторий (Рисунок 26).



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

Теперь связываем локальный и удалённый репозиторий при помощи специальной команды:

git remote add project [e-mail]:sssabd/repo2.git

Создаём ветку branch1. Делаем изменение в файле и производим коммит:

git checkout -b main

nano readme.txt

nano file.html

git add readme.txt

git add file.html

git commit -m "Added first changes into file"

После этого переключаемся на ветку main и сливаем туда branch1 (Рисунок 27).

git checkout master

git merge branch1



Рисунок 27 – Результат слияния веток

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

1. 
   Клонируем непустой удалённый на локальную машину репозиторий (Рисунок 28), воспользовавшись командой:
   

git clone <ссылка на репозиторий>

cd project1



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

2. 
   Создадим новую ветку и выведем список всех веток (Рисунок 29), используя команды:
   

git checkout -b branch1

git branch --list



Рисунок 29 – Создание новых веток

3. 
   Произведем 3 коммита в новой ветке branch1 (Рисунок 30), повторяя команды:
   

nano test.html

git add test.html

git commit -m “Added into file”



Рисунок 30 – Коммиты в ветке branch1

4. 
   Выгружаем изменения в удалённый репозиторий (Рисунок 31), используя команду:
   

git push origin branch1



Рисунок 31 – Выгрузка изменений

Зайдя в удаленный репозиторий, мы увидим, что там появилась новая ветка branch1 (Рисунок 32).



Рисунок 32 – Изменения в удаленном репозитории

5. 
   Откатим в новой ветке предпоследний коммит (Рисунок 33). Для этого сначала убедимся, как выглядит последняя версия перед удалением, а затем удалим последний созданный коммит с помощью команды:
   

cat test3.html

git revert HEAD –-no-edit



Рисунок 33 – Удаление последнего коммита

Выгрузим изменения в удаленный репозиторий (Рисунок 34), используя команду:

git push origin branch1



Рисунок 34 – Выгрузка последних изменений

Смотрим, удалилась ли последняя версия в удаленном репозитории (Рисунок 35).



Рисунок 35 – Успешный откат к предпоследнему коммиту

6. 
   Выведем в консоль различия между веткой main и branch1(Рисунок 36), используем для этого команду:
   

git diff main branch1



Рисунок 36 – Различия между ветками

7. 
   Сольем новую ветку с main при помощи merge (Рисунок 37)
   

git merge branch1



Рисунок 37 – Сливаем ветки merge и main

Часть 3. Работа с ветвлением и оформлением кода

Задание

Создайте и разрешите конфликты в репозитории, согласно варианту:

1. 
   Сделайте форк репозитория в соответствии с вашим вариантом
   
2. 
   Склонируйте его на локальную машину
   
3. 
   Создайте две ветки branch1 и branch2 от последнего коммита в master'е
   
4. 
   Проведите по 3 коммита в каждую из веток, которые меняют один и тот же кусочек файла
   
5. 
   Выполните слияние ветки branch1 в ветку branch2, разрешив конфликты при этом
   
6. 
   Выгрузите все изменения во всех ветках в удаленный репозиторий
   
7. 
   Проведите еще 3 коммита в ветку branch1
   
8. 
   Склонируйте репозиторий еще раз в другую директорию
   
9. 
   В новом клоне репозитории сделайте 3 коммита в ветку branch1
   
10. 
    Выгрузите все изменения из нового репозитория в удаленный репозиторий
    
11. 
    Вернитесь в старый клон с репозиторием, выгрузите изменения с опцией --force
    
12. 
    Получите все изменения в новом репозитории
    

Вариант 4. https://github.com/ripienaar/free-for-dev
Ход работы

Производим форк репозитория своего варианта. После этого создастся точная копия репозитория (рисунок 38).



Рисунок 38 – Результат форка репозитория

Клонируем его на свою локальную машину с помощью команды (Рисунок 39):

git clone <ссылка на репозиторий>



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

Создаём 2 новые ветки:

git checkout -b branch1

git checkout -b branch2

Проводим по 3 коммита в каждой из веток. При этом изменяем один и тот же кусок файла.

В ветке branch1 используем 3 раза команды, чтобы изменить содержимое файла README.md:

nano README.md

git add README.md

git commit -m “git commit -m "Changed README.md 1/2/3”

В ветке branch2 используем 3 раза команды, чтобы изменить содержимое файла README.md:

nano README.md

git add README.md

git commit -m “git commit -m "Changed README.md 4/5/6”

Сливаем ветку branch1 в ветку branch2, разрешая при этом возникающие конфликты.

git merge branch1

После команды содержимое изменилось (Рисунок 40)



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

Нужно вручную отредактировать конфликтный файл, при этом не забывая удалить метки, оставленные Git. Файл после удаления меток показан на рисунке 41.



Рисунок 41 – Файл, после удаления меток вручную

Затем ввести команды:

git add README.md

git commit -m 'merged A and B'

После чего конфликт решается и ветки сливаются. Выгружаем изменения во всех ветках в удалённый репозиторий, используя команду (Рисунок 42):

git push origin

git checkout



Рисунок 42 – Выгрузка изменений

Производим ещё три коммита в ветке branch1. В ветке используем 3 раза команды, чтобы изменить содержимое файла README.md:

nano README.md

git add README.md

git commit -m “git commit -m "Changed README.md 7/8/9”

Снова клонируем репозиторий уже в другую директорию с помощью команды (Рисунок 43):

git clone <ссылка на измененный нами репозиторий>



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

Производим три коммита в ветке branch1. В ветке используем 3 раза команды, чтобы изменить содержимое файла README.md:

nano README.md

git add README.md

git commit -m “git commit -m " Changed README.md 10/11/12”

Выгружаем изменения в удалённый репозиторий (Рисунок 44).



Рисунок 44 – Выгрузка изменений

Переходим в первый клон и принудительно выгружаем изменения (Рисунок 45), используя команду:

git push origin branch1 --force



Рисунок 45 – Принудительная выгрузка изменений

Используем команду git pull в новом репозитории.



Рисунок 46 – Получение изменений в новом репозитории

Возникает конфликт, который исправляется аналогично описанному выше. После разрешения конфликта команда выдает такой результат (Рисунок 47).



Рисунок 47 – Повторное написание команды

Ответы на контрольные вопросы

Вопрос 1.

Какие существуют типы систем контроля версий? Приведите примеры к каждому типу.

Ответ: Системы контроля версий бывают локальными, централизованными или распределёнными.

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

Примеры: локальная – RCS (Revision Control System), централизованные – Subversion, распределенные – Git, Mercurial.

Вывод

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

Список использованных источников и литературы

Лекции по дисциплине «Технология разработки программных приложений».

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