Использование GitHub в обучении студентов

Статьи впервые опубликованы на портале Хабр:

• Использование 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)
• C#
  • ООП
  • сетевое программирование
  • 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