Не только Git…

(повторение) Git: DVCS

1. Версионирование
2. Хранение
3. Работа с историей изменений в виде орграфа (сети)
   • Ветки
   • Изменение истории
   • …
4. Информационное пространство:

   • Описание процесса (коммит сообщения)

   • Маркировка отдельных точек (теги)
     • В т. ч. аннотированные и подписанные теги
   • …

Организация взаимодействия при совместной разработке

Запрос на объединение

(merge request, pull request, …) — часть дисциплины распределённой совместной разработки, в которой предполагается, что у каждого разработчика имеется собственный репозиторий, и только в него можно делать коммиты. Для того, чтобы другой разработчик смог вовремя синхронизировать свой репозиторий с результатами работы первого, его нужно уведомить о том, что работа проделана.

Модели ведения репозитория

Классическая модель

• Один публичный репозиторий, т. н. «апстрим»
• Разработчики синхронизуются с ним

• Запросом на объединение является электронное письмо с приложенным набором патчей

  • в git есть поддержка этого процесса (git send-email)

• Майнтейнер публичного репозитория делает git am и ревью, и публикует результат

Открытая модель:

• Апстрим — один публичный репозиторий (т. н. «Precious source»), в котором собирается работа всех участников

  • в этот репозиторий делается только pull и review

  • если майнтейнер precious source сам тоже ведёт разработку, то в отдельном репозитории (вариант послабее — в отдельной ветке)
• Разработчики синхронизуются с precious source
• Индивидуальные публичные репозитории всех участников
• Решённые (под)задачи участники публикуют в индивидуальных публичных репозиториях

• Запросом на объединение является оповещение о готовности индивидуального репозиотрия к merge-у со стороны исполнителя (ссылка на commit-ish — коммит, тег, ветку и т. п.)

• Майнтейнер апстрима делает git merge и ревью, и публикует результат

Модель общего хостинга:

• В плане использования GIT совпадает с открытой моделью

• Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют

• Запрос на объединение — отдельный информационный объект в движке хостинга («pull request» для GitHub или «merge request» для GitLab); движок обеспечивает (полу)автоматическую его обработку и информационное пространство (обсуждение, ссылки и т. п.)

  • Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения
• Предоставляет тематическую социальную сеть с привязкой к исходным текстам и информационным объектам процесса разработки
• Предоставляет технологические ресурсы по сборке и тестированию

Централизованная модель:

• Один репозиторий для всех
• Чёткие конвенции для push и pull
• Использование веток в т. ч. для индивидуальной разработки
  • Решённые (под)задачи участники публикуют в том же самом репозитории в специально выделенных личных ветках разработки
• Важно: раздельных прав доступа на части репозитория в git нет, это или договорённости или дополнительные свойства площадки
• (А ещё это сводит на нет все достоинства DVCS)
• Тем не менее этот вариант эффективен для малых сообществ с единым управлением и большим количеством нецифрового общения (например, команда, целиком сидящая в офисе)

  • Мы не будем использовать этот вариант в семестровых проектах (таково условие)

Пример параллельной разработки

TODO

Ветки и индивидуальные публичные репозитории — ортогональные сущности

• Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel - testing - production)
• Индивидуальные публичные репозитории — для разделения областей ответственности по исполнителям
• В индивидуальном репозитории могут быть какие угодно ветки, например, один и тот же человек может

  1. заниматься разработкой новой фичи — иметь соответствующую ветку в своём публичном репозитории и слать pull-request-ы в ветку newfeature апстрима

  2. заниматься багфиксом релизов и слать pull-request-ы в ветку production апстрима

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

git remote (ещё тут)

• Общая история
• Произвольная синхронизация
• Но: нет встроенных инструментов уведомления
  • (actually, есть — email — но даже он требует инфраструктуры ≠ git: почтовых серверов, email-клиентов и т. п.)

Cmd и асинхронные сообщения

Проблема: ввод командной строки с помощью readline, подстановка в cmd и прочее — синхронные операции. Предположим, пользователь вводит команду, а в это время прилетает сообщение. Что делать?

Воспользоваться одновременно asyncio и синхронной обработкой ввода нельзя.

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

• Это можно делать в отдельном процессе (см. multiprocessing) или в отдельном потоке (см. threading). Оба варианта выводят текст на тот же stdout, что и основная программа.

• Нам понадобится заново вывести

  1. Подсказку cmd (её можно взять из самой командной строки)

  2. Текст, который пользователь начал вводить в cmd, но ещё не нажал перевода строки. Этот текст доступен в буфере библиотеки readline ( на Windows может не работать)

   1 import cmd
   2 import threading
   3 import time
   4 import readline
   5 
   6 
   7 class simple(cmd.Cmd):
   8 
   9     def do_echo(self, arg):
  10         print(arg)
  11 
  12 
  13 def spam(cmdline, timeout, count):
  14     for i in range(count):
  15         time.sleep(timeout)
  16         print(f"\nI'm a message № {i}!\n{cmdline.prompt}{readline.get_line_buffer()}", end="", flush=True)
  17 
  18 
  19 cmdline = simple()
  20 timer = threading.Thread(target=spam, args=(cmdline, 3, 10))
  21 timer.start()
  22 cmdline.cmdloop()

Д/З

Основное задание

1. Написать простой netcat-образный клиент для «коровьего чата» из задания по прошлой лекции. Достаточно модифицировать последний пример из лекции. Написать cmd-поддержку команд чата в клиенте и обеспечить completion по именам коров.

   • В login completion должен сначала выполнять cows на сервере, и предлагать результаты оттуда

   • Аналогично, в say completion должен сначала выполнять who на сервере, и предлагать результаты оттуда

2. Разработку клиента вести согласно дисциплине оформления коммитов в подкаталоге 06_SocialProject отчётного репозитория по Д/З

Обратите внимание на то, что это сравнительно невинное изменение меняет протокол работы с сервером: помимо «просто» сообщений из чата появляется сообщение-ответ на определённую команду-запрос. Самый простой способ не запутаться — это ввести уникальный номер запроса сопровождать ответ им. Например, простое сообщение всегда начинается на пробел, а ответ на команду — на номер поданной в данном сеансе команды.

Регистрация семестрового проекта

0. Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиторий не надо)
1. Разработать драфт проектного задания;
   • Постановка решаемой задачи: один абзац или список фич
   • Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)

   • Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть

     • GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
     • Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
     • …
     • Поместить проектное задание в README (или README.md) публичного репозитория

2. Зарегистрировать публичный репозиторий проекта в качестве вашего персонального issue на странице репозитория PythonDevelopment2023. В issue указать:

   • Короткую формулировку сути проекта

   • Ссылку на публичный репозиторий проекта

   • Список участников проекта в виде:
     1. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории
     2. ФИО, группа (факультет, если не ВМК) и nick, под которым появляются коммиты в репозитории …

3. См. требования к защите проекта