Статьи впервые опубликованы на портале Хабр:
- Использование GitHub в обучении студентов - https://habr.com/ru/post/533940/
- Вариант с форками - https://habr.com/ru/post/534198/
- Вариант командной работы - https://habr.com/ru/post/534292/
- Вариант командной работы с несколькими репозиториями - https://habr.com/ru/post/536590/
В своей преподавательской практике использую GitHub...
Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог. А ещё - один из основателей и ведущих подкаста "IT за Edu".
Мой стек дисциплин:
+ C++
- основы программирования
- основы ООП
- GUI-приложения (Qt)
+ CSharp
- ООП
- сетевое программирование
- GUI-приложения (WPF)
- взаимодействие приложений и БД (ADO.Net)
+ Базы данных
- проектирование БД
- SQLite
- MySQL
+ Управление проектами
Кажется, что всего много. Но успеваем не сильно погрузиться в отдельные технологии. После какого-то времени (точно не помню уже какого) понял, что студентов можно, и даже нужно, "приучать" к системам управления версиями почти сразу - с начала обучения. Для обучения выбрал GitHub. Хотя Bitbucket тоже нравится. Да, я не учу студентов сразу по харду, они не сразу изучают git в CLI. Я их знакомлю сначала с web-интерфейсом GitHub'а. Потом рассказываю про GUI-клиенты. Из них мне нравится GitKraken. Но не заставляю их пользоваться тем, что нравится мне - они вольны выбирать сами чем пользоваться.
Постепенно - это примерно так:
1. Просто показываю как выкладывать код
2. Прошу их выкладывать свои решения и присылать мне ссылки на репозитории
3. Выкладываю текст заданий и прошу ответы присылать через pull-request'ы
4. Пробуем поработать в маленьких командах над одним репозиторием без веток
5. Пробуем поработать небольшой командой над одним репозиторием с отдельными ветками
6. Пробуем работать над большим проектом большой командой с несколькими репозиториями и ветками.
И вот такой постепенный подход стараюсь применять при изучении тем. Иногда темы заканчиваются быстрее, чем успеем перейти к большому или маленькому проекту. Но это несильно страшно. По изучении нескольких тем мы можем полученные знания объединить в один большой проект.
Не все студенты сразу всё понимают и принимают. Но тем интереснее и приятнее когда они "доходят". Ещё люблю подход: учимся на своих ошибках. Во время обучения есть возможность ошибаться и понять к чему это приводит.
Что мне нравится в GitHub при обучении?
- Поддержка аккаунтов для организаций, а в аккаунтах возможность создания команд с гибкими настройками доступов
- Поддержка Markdown-разметки. Можно более "красиво" оформлять задания.
- Система форков. Может любой человек сделать форк, а потом предложить запрос на слияние. Не всегда нужно всех студентов добавлять в команду.
- Возможность комментировать участки кода при проведении ревью. Очень удобно указывать на сильные и слабые моменты в программах.
- Возможность назначать ревьюером любого члена команды. Студенты должны уметь не только хорошо писать программы, но и проверять чужой код.
- Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues.
Для чего я приучаю студентов к GitHub'у?
- Создание своего портфолио уже с самого начала обучения, а не только под конец.
- Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают
- Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают
- Понимание как работать в команде. И как командам между собой взаимодействовать.
Прекрасно понимаю, что мои методы не самые лучшие и далеки от совершенства, да и от реальности далековаты. Но стараюсь их приблизить к реальности.
.Вариант с форками.
Начну с варианта, когда не обязательно добавлять студентов в аккаунт организации. Т.е. можно и в своём аккаунте делать репозитории с заданиями.
.Примерный порядок действия.
- Создаёте репозиторий с названием задания.
- В README.md добавляете текст задания и подробную (желательно, но не обязательно) инструкцию что и как должны сделать. Обязательно обращаете внимание на создание форка и после выполнения (читай, наполнения репозитория) создания запроса на слияние (pull request) с вашим исходным репозиторием.
Пример - https://github.com/college-VIVT/TerminalEmulator
В нужном месте сообщаете студентам задание и ссылку на репозиторий.
- Ждёте выполнения задания, а точнее создания запроса на слияние.
- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
- Принимать (мерджить) запрос на слияние в данной ситуации не нужно. Если всё хорошо - то можно просто оставить комментарий в ревью кода. Если всё плохо - то не принимаете.
.Плюсы и минусы.
Плюсы:
- Не нужен аккаунт организации
- Можно рассылать любому количеству студентов, даже из разных групп или учебных заведений
Минусы:
- Нужно следить, чтобы не сделали мердж
- Нужно объяснять что такое форк и запрос на слияние (у некоторых моих студентов это вызвало дополнительные затруднения)
- Сложности с принятием запросов Approve . Мне хочется, чтобы в репозитории было только задание и не было кода решения от студентов.
Какие можно внести дополнения: добавить под каждого студента свою ветку, но это лишние действия при создании и дальнейшем наполнении репозитория.
.Вариант командной работы.
Продолжу вариантом про командную работу. Но рассмотрю ту его версию, когда нет большого числа репозиториев и веток. Про работу большой команды расскажу, наверное, в отдельном посте.
.Примерный порядок действия.
- Создаёте аккаунт организации
- Добавляете в него студентов.
- Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
- Студенты получив задания, делают ответвления от последнего коммита. Выполняют задания, коммитят. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
- Создают запрос на слияние
- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
Плюсы и минусы
Плюсы:
- Более приближенный к реальности вариант моделирования
- Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
Минусы:
- Нужно создавать отдельный аккаунт для организации
- Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
Какие можно внести дополнения: связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках.
.Вариант командной работы с несколькими репозиториями.
Расскажу про "самый приближённый" к реалиям вариант, когда в рамках реализации одной программы возникают подпроекты и над ними трудятся разные команды в разных репозиториях.
.Примерный порядок действия.
Часть действий повторяются из предыдущего примера.
- Создаёте аккаунт организации
- Добавляете в него студентов.
- Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
- Студенты получив задания, клонируют репозиторий себе на локальные машины.
- По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.
- Команды выполняют задания, коммитят, пушат. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
- Создают запрос на слияние
- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
- Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.
- В каждой команде ведётся техдокументация.
Плюсы и минусы
Плюсы:
- Более приближенный к реальности вариант моделирования
- Можно назначать студентов в качестве ревьюеров кода. Даже преподавательского. Я люблю делать в коде специально ошибки как явные, так и неявные, чтобы студенты их находили и исправляли.
- Каждая команда работает над своим подпроектом
- Студенты пробуют межкомандное взаимодействие при разработке одного большого проекта.
Минусы:
- Нужно создавать отдельный аккаунт для организации
- Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
- Нужно объяснять что такое релиз, как происходит версионирование.
- Нужно объяснять как пишется и для чего нужна техдокументация.
Какие можно внести дополнения:
- связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках
- создавать не отдельные репозитории для каждого подпроекта, а использовать git submodules
