Создание сайтов: лендинг, визитка, интернет магазин. Продвижение, поддержка, реклама.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

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

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

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

Минусы:

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

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

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

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

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

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

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