.Использование GitHub в обучении. Примеры. Часть III

Моя цель - предложение широкого ассортимента товаров и услуг на постоянно высоком качестве обслуживания по самым выгодным ценам.

Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы:

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

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

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

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

Минусы:

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

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

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

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

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

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

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

Источник: https://habr.com/ru/post/536590/


Интересные статьи

Интересные статьи

Это четвертая и финальная часть из серии моих публикаций, посвященных вопросу ввоза обедненного гексафторида урана (ОГФУ) из Европы в Россию. Первая посвящена технологиям обогащения у...
Выход PostgreSQL 13, о возможностях которого мы уже писали, планируется только осенью. Ничего принципиально нового в нем уже не появится. Поэтому самое время перейти к PostgreSQL 14. ...
Недавно Дэвид О’Брайен открыл свою собственную компанию Xirus (https://xirus.com.au), сосредоточившись на облачных продуктах Microsoft Azure Stack. Они предназначены для согласованного создания и...
Технологии компьютерного зрения позволяют в сегодняшних реалиях сделать жизнь и бизнес проще, дешевле, безопаснее. По оценкам разных экспертов этот рынок будет двигаться в ближайшие годы толь...
В данной статье угоняем куки через Stored XSS, разбираемся с CSRF атакой и реверсим Flash SWF файл. Ссылки на предыдущие статьи: Часть 1: Web — javascript authentication, obfuscation и nativ...