Не только Git…

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

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

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

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

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

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

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

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

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

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

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

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

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

  • в этот репозиторий делается только merge и 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)
• Тем не менее этот вариант эффективен для малых сообществ с единым управлением и большим количеством нецифрового общения (например, команда, целиком сидящая в офисе)

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

Принятие коммитов в репозиторий

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

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

Ревью

(code reviwew) — часть дисциплины совместной разработки, в которой никакой коммит не появляется в истории, пока его не одобрит специально выбранный для этой роли участник. Это может быть лид или просто ещё одинчлен команды

• Для централизованной модели отсутствие ревью фатально (как и отсутствие многих других элементов дисциплины)

• Для распределённых моделей ревью «подразумевается» (кто-то же должен сделать merge commit)

Во всех случаях элементы социального взаимодействия (уведомления, обсуждение и т. п.) в самом git не реализованы — это функции хостинга.

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

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

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

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

В централизованной схеме ветки играют обе роли.

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

На примере самого Python

• Ветки — это:
  0. Основная разработка
  1. Релизы (видимо, поддерживаемые)
  2. Большие направления разработки / тестирования

• Часть работы — pull request-ы со стороны обширного сообщества

• Часть — совместный доступ относительно небольшого числа core-разработчиков

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

При использовании схемы «Precious source» — минимум двумя (свой и апстримный).

git remote (ещё тут)

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

Пример:

0. Оба участника заводят пустые репозитории, подготавливают их к публикации и публикуют

      1 srv:~/joined$ git init --bare repo
      2 srv:~/joined$ cp repo/hooks/post-update.sample repo/hooks/post-update
      3 srv:~/joined$ git init --bare comm_repo                              
      4 srv:~/joined$ cp comm_repo/hooks/post-update.sample comm_repo/hooks/post-update 
      5 srv:~/joined$ python3 -m http.server &
   

1. В нашем случае запушить по протоколу http: нельзя, но зато можно запушить в соседний каталог

      1 srv:~/joined$ git clone repo owner
      2 srv:~/joined$ cd owner 
      3 srv:~/joined/owner$ cal > calendar
      4 srv:~/joined/owner$ git add .
      5 srv:~/joined/owner$ git commit -m "Initiail"
      6 srv:~/joined/owner$ git push     
      7 srv:~/joined/owner$ cd ..
   

2. Коммиттер добавляет публичный репозиторий разработчика как второй remote, что-то меняет и публикует изменения в своём публичном репозитории

      1 srv:~/joined$ git clone comm_repo committer
      2 srv:~/joined$ cd committer 
      3 srv:~/joined/committer$ git remote add upstream http://localhost:8000/repo
      4 srv:~/joined/committer$ git remote -v
      5 srv:~/joined/committer$ git pull upstream master 
      6 srv:~/joined/committer$ date >> calendar 
      7 srv:~/joined/committer$ git commit -a -m "Add date"
      8 srv:~/joined/committer$ git push                
   

3. Комиттер как-то даёт знать разработчику о том, что пора принимать работу.

4. Разработчик добавляет публичный репозиторий коммиттера как второй remote, и мержится с ним (pull — это fetch + merge)

      1 srv:~/joined/committer$ cd ../owner 
      2 srv:~/joined/owner$ git remote add comm http://localhost:8000/comm_repo
      3 srv:~/joined/owner$ git pull comm master 
   

Обычно коммиттер сообщает разработчику ещё commit ID — тогда pull превращается в fetch + merge commitID

Резюме: чего не умеет Git?

• Прямая коммуникация пользователей

• Гипертекстовое (с перекрёстными ссылками) представление — как документации, так и внутри коммуникационного поля

• События и уведомления

  • На самом деле средства привязки внешних инструментов к некоторым событиям в репозитории есть — это Git Hooks (лежат в каталоге .git/hooks)

  • Всю логику и тем более транспорт (доставку) порождаемого потока служебных данных (запросов, уведомлений, переписку и т. п.) надо делать / разворачивать самостоятельно, git в это не умеет

Пример: pre-commit hook

Есть даже целый пакет — pre-commit

• TODO прокликать пример.

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

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

Воспользоваться одновременно asyncio и синхронной обработкой обычного ввода нельзя: пока происходит ввод, сообщения накапливаются ⇒ изменится их порядок.

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

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

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

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

  2. Текст, который пользователь начал вводить в cmd, но ещё не нажал перевода строки.

     • Этот текст доступен в буфере библиотеки readline ( на Windows может не работать)

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

• Функция spam() запущена в отдельном потоке, и раз в timeout секунд выводит сообщение и восстанавливает подсказку cmdline + уже введённую часть команды

• Командная строка предельно простая — есть команда echo

Д/З

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В семестровом проекте требуется использовать схему с precious source репозиторием для публикации и отдельными репозиториями разработчиков.