03.03 git: работа с ветками

Прежде всего: разберёмся с основной веткой Д/З. Она должна называться work. Если у вас не так (например, main), то:

• git clone репозиторий

• git branch -m старый_бранч work

• git push --set-upstream origin work 

И в последующие разы всегда делать

• git clone репозиторий -b work

План занятия:

0. разогрев
   • беглое повторение про ветки (из лекции)

   • qgit и полная история

   • пример с ребейзом

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

   • пример с мержем (ветку используем с предыдущего примера)

     • переключиться на master
     • сделать в master два коммита
     • переключиться на ветку
     • сделать на ветке два неконфликтующих коммита
     • помержить ветку с master-ом
     • увидеть мерж-коммит и граф истории

   • пример с «переотрастанием» ветки при rebase (aka «ветка — не ветка»)

     • создать историю из 4 коммитов
     • сделать ветку, совпадающую с master

     • на ветке сделать rebase -i на два шага истории назад

     • исправить самый первый коммит (достаточно reword в commit message!)
     • убедиться, что ветка теперь отрастает из другого места (а git diff ничего не показывает)

1. Создать отдельный репозторий

   • сделать в нём 5 коммитов

   • сделать ветку rebased. на этой ветке с помощью git rebase --root -i:

     • переставить второй и третий коммит
     • слить четвёртый и пятый коммит в один

     $ git -P log --all --graph --oneline
     * 4c7af4d (HEAD -> rebased) Commit 4
     * 802744a Commit 2
     * 2ecda85 Commit 3
     | * de9f9b5 (master) Commit 5
     | * a5bac51 Commit 4
     | * 715e908 Commit 3
     | * 69f72f5 Commit 2
     |/  
     * d26fec6 Commit 1

2. Работа с модулем shlex (нe было на лекциях)

   • split, join и quote

   • Ввести одну строку — командную строку воображаемого интерпретатора — и «причесать» её: удалить лишние пробелы, нормализовать кавычки и т. п.

   • Имеются две строки: ФИО (с пробелами) и место рождения с указанием типа места рождения (может содержать кавычки, например, гостиница "Рояль"). С помощью shlex.join() сформировать командную строку, вида register ФИО МЕСТО, в которой у register ровно два параметра

     • Вывести этот ужасрезультат на экран

   • (Продолжение)

     • Ввести результат прошлого упражнения и проверить с помощью shlex.split(), что строка имеет правильный формат

     • (TODO сформулировать пояснее) Подобрать более простую комбинацию кавычек (\"), которая давала бы тот же результат после shlex.split()

TODO успели на полчаса раньше

Д/З

Задача_1: работа с ветками в git при разработке программы

• В решении Задачи_2 с предыдущего занятия сделайте merge ветки named_monsters на ветку work

• Скопируйте решение Задачи_2 с предыдущего занятия. Сделайте коммит. Далее этот коммит будет обозначаться как

• Продолжите историю на ветке work:

  • Реализуйте вывод, при старте программы, строки-приветствия "<<< Welcome to Python-MUD 0.1 >>>"

  • Сохраните вывод строки-приветствия в виде одного коммита

• Создайте ветку shlex_parse на базе коммита и переключитесь на неё (проверьте!)

• Реализуйте на ветке shlex_parse:

  • разбор команд MUD при помощи shlex вместо ранее реализованного разбора

  • поддержку команды addmon с синтаксисом (взамен прежнего синтаксиса): addmon <monster_name> hello <hello_string> hp <hitpoints> coords <x> <y>, где:

    • hello, hp, coords - имена параметров команды, все параметры обязательные

    • <hello_string> - строка приветствия, которую "произносит" монстр при встрече; может быть строкой с пробелами, заключенной в кавычки

    • <hitpoints> - положительное целое, задающее количество очков здоровья монстра (должно запоминаться вместе с именем монстра и строкой приветствия)

    • <x>, <y> - координаты монстра

    • порядок следования именованных параметров произвольный, например: addmon dragon hp 999 coords 6 9 hello "Who goes there?"

  • разбиение на коммиты - на ваше усмотрение, но коммитов на ветке должно быть не менее двух

• Посмотрите структуру веток в qgit

• Сделайте merge ветки shlex_parse на ветку work

• Посмотрите структуру веток в qgit; обратите внимание на merge-коммит и на порядок следования коммитов в "суммарной" истории до merge-коммита

• Создайте ветку custom_monster на базе коммита и переключитесь на неё (проверьте!)

• Реализуйте на ветке custom_monster поддержку нового монстра

  • монстр выглядит так: (пожалуйста, не удаляйте инициалы jgs - это условие использования, заданное автором Joan G. Stark)

        ,_                    _,
        ) '-._  ,_    _,  _.-' (
        )  _.-'.|\\--//|.'-._  (
         )'   .'\/o\/o\/'.   `(
          ) .' . \====/ . '. (
           )  / <<    >> \  (
            '-._/``  ``\_.-'
      jgs     __\\'--'//__
             (((""`  `"")))

  • поддержка монстра реализуется при помощи read_dot_cow(), см. пример на https://pypi.org/project/python-cowsay/

  • имя монстра "jgsbat"

  • должна быть реализована поддержка добавления этого монстра на игровое поле по команде addmon, с указанием имени монстра (наравне со "стандартными" персонажами python-cowsay)

• Сделайте rebase ветки work (где к этому шагу будет merge-коммит) на ветку custom_monster

• Внимание! в результате именно ветка work должна вобрать в себя все коммиты (т.е. команда должна быть git rebase custom_monster work)

• посмотрите структуру веток в qgit