Использование GitHub в обучении. Примеры. Часть III09.01.2021 20:17

Продолжу выкладывание примеров использования GitHub’а как инструмента обучения.


→ Предыдущий пример

Вариант командной работы с несколькими репозиториями

Расскажу про «самый приближённый» к реалиям вариант, когда в рамках реализации одной программы возникают подпроекты и над ними трудятся разные команды в разных репозиториях.

Примерный порядок действия

Часть действий повторяются из предыдущего примера

  • Создаёте аккаунт организации

42f435052c9904e554e795284934e9c1.png

  • Добавляете в него студентов.

889b329140ee8d109318443f5e59037f.png

  • Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop

3f1149cc99900bf4d19551f5df634a29.png

  • Студенты получив задания, клонируют репозиторий себе на локальные машины.

ee9e2fce8fe728b2132c9653c74e8855.pngbf7f6a0ca0b8192e40afeb2cdfdf462e.png

  • По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.

8d68321d611a6eed2acf2d5bdbfecaad.pngad4639f7e13b6739d5be8014fb9b9afa.png

  • Команды выполняют задания, коммитят, пушат. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum

9c0c2a8acb910f7d4128824f689d37df.png

  • Создают запрос на слияние

ee4fc7e41f8f73bfb52f1491bd1f550b.png

  • Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.

ded20051e777f12948314d44bb9f2259.png0653bbbea8294231e498810156f6605a.png

  • Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.

bbff3f920864f8ef48b8364511b49321.png

  • В каждой команде ведётся техдокументация.

39ded6e51c41f6ea84a6b4162056df09.png

Плюсы и минусы

Плюсы:

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

  • Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.

  • Каждая команда работает над своим подпроектом

  • Студенты пробуют межкомандное взаимодействие при разработке одного большого проекта.

Минусы:

  • Нужно создавать отдельный аккаунт для организации

  • Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.

  • Нужно объяснять что такое релиз, как происходит версионирование.

  • Нужно объяснять как пишется и для чего нужна техдокументация.

Какие можно внести дополнения:  

  • связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках

  • создавать не отдельные репозитории для каждого подпроекта, а использовать git submodules

© Habrahabr.ru