Различия между версиями 17 и 18
Версия 17 от 2023-02-27 15:56:57
Размер: 7889
Редактор: FrBrGeorge
Комментарий:
Версия 18 от 2023-05-27 22:09:21
Размер: 7898
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 39: Строка 39:
 1. <!> '''Задача_1''': работа с ветками в git при разработке программы == Д/З ==
<!> '''Задача_1''': работа с ветками в git при разработке программы

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

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

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

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

  • git push --set-upstream origin work 

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

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

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

  1. разогрев
    • беглое повторение про ветки (из лекции)
    • qgit и полная история

    • {OK} пример с ребейзом

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

      • переключиться на master
      • сделать в master два коммита
      • помержить ветку с master-ом
      • увидеть мерж-коммит и граф истории
    • {OK} пример с «переотрастанием» ветки при rebase (aka «ветка — не ветка»)

      • создать историю из 4 коммитов
      • сделать ветку, совпадающую с master
      • на ветке сделать rebase -i на два шага истории назад

      • исправить самый первый коммит (достаточно reword в commit message!)
      • убедиться, что ветка теперь отрастает из другого места (а git diff ничего не показывает)
  2. Работа с модулем shlex (на было на лекциях) — split, join и quote

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

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

      • Вывести этот ужас на экран
    • {i} (Продолжение)

      • Проверить с помощью shlex.split(), что оно именно так

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

Д/З

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

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

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

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

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

    • Сохраните вывод строки-приветствия в виде одного коммита
  • Создайте ветку shlex_parse на базе коммита {1} и переключитесь на неё (проверьте!)

  • Реализуйте на ветке 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 на базе коммита {1} и переключитесь на неё (проверьте!)

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

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

          ,_                    _,
          ) '-._  ,_    _,  _.-' (
          )  _.-'.|\\--//|.'-._  (
           )'   .'\/o\/o\/'.   `(
            ) .' . \====/ . '. (
             )  / <<    >> \  (
              '-._/``  ``\_.-'
        jgs     __\\'--'//__
               (((""`  `"")))
    • поддержка монстра реализуется при помощи read_dot_cow(), см. пример на https://pypi.org/project/python-cowsay/

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

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

  • Добавьте историю (rebase) ветки custom_monster на ветку work (где к этому шагу будет merge-коммит)

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

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

LecturesCMC/PythonDevelopment2023/Prac/03_DvcsBranchMerge (последним исправлял пользователь FrBrGeorge 2023-05-27 22:09:21)