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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

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

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

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

Минусы:

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

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

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

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

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

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

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