Лабораторная работа №3.

Продвинутая работа с Git: Удаленные репозитории, Перебазирование и Управление конфигурацией

Цель работы: Закрепить на практике работу с удаленными репозиториями, освоить процесс перебазирования, научиться управлять конфигурацией Git и работать с тегами.

Команды для использования в работе: git clone, git config, git remote, git branch, git switch/checkout, git add, git commit, git rebase, git tag, git fetch, git push.

---

1. Клонирование репозитория и конфигурация.

1.1. Сделайте форк этого репозитория, нажав "Fork" в левом верхнем углу экрана.

1.2. На странице репозитория СВОЕГО ФОРКА скопируйте URL.

На вашем компьютере, перейдите в папку, в которой будет ваш репозиторий. Откройте там терминал.

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

1.3. Установите локальные настройки имени пользователя и email для этого конкретного репозитория (это важно для отслеживания авторства коммитов).

Заметка: Проверить, что настройки применились, можно командой git config --list. Вы должны увидеть установленные вами значения в конце списка.

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

Измените свой удалённый репозиторий, дав удаленному репозиторию имя upstream (общепринятая практика).

Проверьте список всех удаленных репозиториев: git remote -v. У вас должно быть два: origin (ваш форк) и upstream (репозиторий преподавателя).

---

2. Перебазирование.

2.1. На ветке main, найдите в репозитории файл player.gd. Откройте этот файл в блокноте (или другом редакторе кода). Найдите и УВЕЛИЧЬТЕ константу "WALK_MAX_SPEED". Сохраните файл. Добавьте файл в индекс и создайте коммит.

2.2. Перейдите в ветке main на 1 коммит назад. В нём, создайте и переключитесь на новую ветку с именем feature. Переходить на несколько коммитов назад можно через HEAD~N, где N - число коммитов, на которые вы хотите откатиться.

2.3. В репозитории найдите файл player.gd. Откройте этот файл в блокноте (или другом редакторе кода). Найдите и УМЕНЬШИТЕ константу "WALK_MAX_SPEED". Сохраните файл. Добавьте файл в индекс и создайте коммит.

2.4. В репозитории найдите файл tile_map.gd. В функции _process(delta: float) в условии if layer_alpha > 0.3: измените конечное значение для сравнения. Сохраните файл. Добавьте файл в индекс и создайте коммит.

2.5. Представьте, что пока вы работали, преподаватель внес важные изменения в исходный репозиторий (в ветку main репозитория upstream). Вам нужно получить эти изменения через git fetch.

Эта команда загрузит последние коммиты из upstream/main в ваш локальный репозиторий, но не будет сливать их с вашей рабочей веткой.

2.6. Теперь вам нужно "переместить" вашу ветку feature на вершину только что полученных изменений из upstream/main. Это сделает историю проекта линейной и чистой.

Убедитесь, что вы находитесь в ветке feature. Выполните перебазирование.

Если конфликтов не возникло, rebase пройдет успешно. Ваш коммит теперь будет находиться поверх актуального состояния upstream/main.

---

3. Публикация результатов и маркировка.

3.1. Так как вы переписали историю (rebase), обычный push не сработает. Нужно отправить изменения с принудительной заменой (--force-with-lease — это безопасная альтернатива --force).

3.2. Ваша работа завершена и готова к "релизу". Создайте аннотированный тег для текущего состояния. Отправьте созданный тег на удаленный репозиторий origin.

3.3. Представьте, что репозиторий upstream больше не нужен. Удалите его из списка удаленных репозиториев.

Проверьте, что он исчез: git remote -v. Должен остаться только origin.

---

Что должно быть в отчёте:

1. Ссылка на ваш форк репозитория. В вашем форке должны быть:
   • Ветка feature с обновленными файлами player.gd и tile_map.gd.
   • Тег v1.0.0, указывающий на последний коммит в ветке feature.
2. Скриншоты, где последовательно видны:
   • ваш форк в изначальном состоянии.
   • git remote -v (после добавления upstream).
   • git config --list (где видны ваши локальные настройки).
   • git log --oneline --graph --all (показывает историю после rebase).
   • git tag -n (показывает список тегов с комментариями).

Контрольные вопросы (обязательно):

1. В чем основное различие между аннотированным тегом и легковесным тегом? Когда стоит использовать каждый из них?
2. Объясните своими словами, в чем ключевая разница между git fetch и git pull. В каком случае вы предпочли бы использовать fetch + merge, а в каком fetch + rebase? Аргументируйте свой ответ.
3. В чём разница между git rebase и git merge? В каких случаях их нужно использовать?