⇤ ← Версия 1 от 2022-03-16 11:33:02
6047
Комментарий:
|
7821
|
Удаления помечены так. | Добавления помечены так. |
Строка 48: | Строка 48: |
'''TODO''' | |
Строка 64: | Строка 63: |
== Семестровый проект == '''TODO''' |
|
Строка 67: | Строка 64: |
'''TODO''' зарегистрировать семестровый проект | [[../GraduateProject|зарегистрировать семестровый проект]] 1.#0 Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиотрий ненадо) 1. Разработать драфт проектного задания; * Постановка решаемой задачи: один абзац или список фич * Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются) * Макет интерфейса (обратите внимание на то, что от проекта ''требуется'' локализация ⇒ ''какой-то'' интерфейс с человеком должен быть * GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое * Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы * … * Поместить проектное задание в README (или README.md) публичного репозиотория 1. Зарегистрировать публичный репозиторий проекта в качестве комментария [[https://github.com/FrBrGeorge/PythonDevelopment2022/issues/2|к этому issue]] 1. См. [[../GraduateProject|требования к защите проекта]] |
Не только Git…
Git: DVCS
- Хранение
- Версионирование
- Работа с историей изменений в виде орграфа
Документирование процесса разработки
- Маркировка отдельных коммитов
- В т. ч. аннотированные и подписанные теги
Организация взаимодействия при совместной разработке
Классическая модель (если не будет хватать времени, рассмотрим только её):
- Один публичный репозиторий
- Разработчики синхронизуются с ним, merge request-ом является письмо с приложенным набором патчей
Майнтейнер публичного репозитория делает git am и ревью
Открытая модель:
- «Precious source» — публичный репозиторий, в который делается только pull
- Индивидуальные публичные репозитории всех участников
- Оповещение о готовности индивидуального репозиотрия к merge-у (pull request) со стороны исполнителя
Майнтейнер precious source делает git pull и ревью
Модель общего хостинга:
В плане использования GIT совпадает с открытой моделью
- Все дополнительные инструменты разработки могут быть привязаны к git или даже управляться тегами, но в самом git отсутствуют
- Например, у понятия merge/pull request даже нет чёткого определения
Выделяют «pull request» (GitHub) или «merge request» (GitLab) в качестве отдельного информационного объекта и обеспечивают (полу)автоматическую его обработку.
- Важно: понятие merge/pull request в самом git отсутствует, и у него нет чёткого определения
- Предоставляет тематическую социальную сеть с привязкой к исходным текстам и информационным объектам процесса разработки
- Предоставляет технологические ресурсы по сборке и тестированию
Централизованная модель:
- Один репозиторий для всех
- Чёткие конвенции для push и pull
- Использование веток в т. ч. для индивидуальной разработки
- Важно: раздельных прав доступа на части репозитория в git нет, это или договорённости или дополнительные свойства площадки
- А ещё это сводит на нет все достоинства DVCS
Ветки и индивидуальные репозитории — ортогональные сущности:
- Ветки — для эшелонирования работ (например, разработки новой функциональности или разделения на devel - texting - deployment)
- Индивидуальные репозитории — для разделения областей ответственности по исполнителям
Работа с несколькими удалёнными репозиториями
git remote (ещё тут)
- Общая история
- Произвольная синхронизация
- Но: нет встроенных инструментов уведомления
- (actually, есть — email — но даже он требует инфраструктуры ≠ git: почтовых серверов, email-клиентов и т. п.)
Информационно-технологическое пространство проекта разработки
- Общение — списки рассылки, «team discussion», чатики, you name it
- Документирование (самого проекта и дисциплины разработки в нём) — Wiki и иные системы публикации
- Issue tracking — ошибки / feauture requests
- Workflow: open → discuss → solve → close (→ reopen → …)
- «Patches are welcome!»
- Частный случай: «pull request» (gitlab: merge request)
- Инфопространство привязано к конкретным точкам разработки
- Эффективно в рамках единого хостинга (в остальных случах просто моделируется, например, тредом в списках рассылки)
- ⇒ может содержать удобные инструменты (например, итерация review)
- Но: «подход от решения»
- CI
- Работа с командой / статистика / аналитика / …
Д/З
зарегистрировать семестровый проект
- Завести один «precious source» репозиторий для merge и публикации проекта и персональные — для разработки (лидеру проекта допустимо вести разработку в отдельной ветке, заводить ещё один репозиотрий ненадо)
- Разработать драфт проектного задания;
- Постановка решаемой задачи: один абзац или список фич
- Описание предполагаемых инструментов решения: какие сторонние модули будут использоваться, в рамках каких сервисов (если предполагаются)
Макет интерфейса (обратите внимание на то, что от проекта требуется локализация ⇒ какой-то интерфейс с человеком должен быть
- GUI/TUI — общий вид окошек, что в целом они делаю и как попадают из одного в другое
- Text — команды, диагностика (в общем плане — когда возникает и как посмотреть), режимы работы
- …
- Поместить проектное задание в README (или README.md) публичного репозиотория
Зарегистрировать публичный репозиторий проекта в качестве комментария к этому issue