Использование GitHub в обучении студентов
Tags: github, education, learning, team
Published: 2022-09-14 14:45:38

*Статьи впервые опубликованы на портале Хабр:*
- *[Использование GitHub в обучении студентов](https://habr.com/ru/post/533940/) - https://habr.com/ru/post/533940/*
- *[Вариант с форками](https://habr.com/ru/post/534198/) - https://habr.com/ru/post/534198/*
- *[Вариант командной работы](https://habr.com/ru/post/534292/) - https://habr.com/ru/post/534292/*
- *[Вариант командной работы с несколькими репозиториями](https://habr.com/ru/post/536590/) - 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 при обучении?
- Поддержка аккаунтов для организаций, а в аккаунтах возможность создания команд с гибкими настройками доступов

![github organizations](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/n686z8dxourekvsfauia.png)
![github organizations teams](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/oowirgqfgv7a9c6bvqvj.png)
![github organizations teams role](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2yq53v0c027wr81g33z3.png)
- Поддержка Markdown-разметки. Можно более "красиво" оформлять задания.
![github markdown](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2n9ki7zmm54o47wbh960.png)
- Система форков. Может любой человек сделать форк, а потом предложить запрос на слияние. Не всегда нужно всех студентов добавлять в команду.
![github forks](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/sq039vqmvffhqlua326h.png)
- Возможность комментировать участки кода при проведении ревью. Очень удобно указывать на сильные и слабые моменты в программах.
![github codereview](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/lb71ka611xptgnubzmu4.png)
- Возможность назначать ревьюером любого члена команды. Студенты должны уметь не только хорошо писать программы, но и проверять чужой код.
- Система issues. Можно давать другим командам студентов задание на проверку кода и выявления багов, с занесением всего в issues.
![github issues](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xv10tamkp6ffh6ub8fqs.png)

Для чего я приучаю студентов к GitHub'у?
- Создание своего портфолио уже с самого начала обучения, а не только под конец.
- Понимание принципов написания кода. Когда начинают чужой код проверять - многое понимают
- Понимание "соглашения об именовании". Пока не наступят на грабли разного именования в одной команде - не понимают. Ну или не все понимают
- Понимание как работать в команде. И как командам между собой взаимодействовать.

Прекрасно понимаю, что мои методы не самые лучшие и далеки от совершенства, да и от реальности далековаты. Но стараюсь их приблизить к реальности.

## .Вариант с форками.
Начну с варианта, когда не обязательно добавлять студентов в аккаунт организации. Т.е. можно и в своём аккаунте делать репозитории с заданиями.

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

- Создаёте репозиторий с названием задания.

- В `README.md` добавляете текст задания и подробную (желательно, но не обязательно) инструкцию что и как должны сделать. Обязательно обращаете внимание на создание форка и после выполнения (читай, наполнения репозитория) создания запроса на слияние (pull request) с вашим исходным репозиторием.
Пример - [https://github.com/college-VIVT/TerminalEmulator](https://github.com/college-VIVT/TerminalEmulator)
В нужном месте сообщаете студентам задание и ссылку на репозиторий.
![readme](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zteunf760hbfq3u5gnoo.png)

- Ждёте выполнения задания, а точнее создания запроса на слияние.
![pull requests](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5gjm0of4dtyhvgpj7qut.png)

- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tol67uks83t0ic90z5w9.png)
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xmbsdhkvaccr5lmo9mwb.png)

- Принимать (мерджить) запрос на слияние в данной ситуации не нужно. Если всё хорошо - то можно просто оставить комментарий в ревью кода. Если всё плохо - то не принимаете.

#### .Плюсы и минусы.
##### Плюсы:

- Не нужен аккаунт организации
- Можно рассылать любому количеству студентов, даже из разных групп или учебных заведений

##### Минусы:

- Нужно следить, чтобы не сделали мердж
- Нужно объяснять что такое форк и запрос на слияние (у некоторых моих студентов это вызвало дополнительные затруднения)
- Сложности с принятием запросов Approve . Мне хочется, чтобы в репозитории было только задание и не было кода решения от студентов.

**Какие можно внести дополнения:** добавить под каждого студента свою ветку, но это лишние действия при создании и дальнейшем наполнении репозитория.

## .Вариант командной работы.

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

### .Примерный порядок действия.
- Создаёте аккаунт организации
![account organization](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zv45pq08uicoo5yz8nrl.png)

- Добавляете в него студентов.
![add students to organization](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ucar8sfyie4069hjdu87.png)

- Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
![create repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/31zd140lkangowm0y2ii.png)

- Студенты получив задания, делают ответвления от последнего коммита. Выполняют задания, коммитят. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
![create issues](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dqdur6fuoqwkagbjoqlq.png)

- Создают запрос на слияние
![create pull request](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/620q9adscoif6c5y92jc.png)

- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/l5bh9gkfer1hy1g3f9x4.png)
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ziws90tfe8b30i7roa1b.png)

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

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

##### Минусы:

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

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

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

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

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

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

- Создаёте аккаунт организации
![account organization](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/uoiyvn85enq05vej2jjd.png)

- Добавляете в него студентов.
![add students to organization](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/524diqt8o75msll92ydq.png)

- Создаёте репозиторий. В README.md добавляете текст задания. Также наполняете репозиторий предварительно необходимым минимумом (нужными файлами для выполнения задания). Создаёте необходимые ветви. Обычно создаю ветвь dev или develop
![create repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/bu2ip1bq5kcronn4zqk5.png)

- Студенты получив задания, клонируют репозиторий себе на локальные машины.
![clone repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/ewjdykawxk9cneuwkxrm.png)
![clone repo](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/yin9j5pdmmvhnyz5l96r.png)

- По мере обсуждения решения выявляются подпроекты. Создаются команды под каждый подпроект. Для каждого подпроекта создаётся свой репозиторий с предварительным наполнением.
![teams](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i7mwwk4d5b2mgtkumja3.png)
![teams](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/olyc44iqpz0jtifznekl.png)

- Команды выполняют задания, коммитят, пушат. Задания можно выдавать как через issues, так и какой-нибудь сервис с Kanban или Scrum
![github projects](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/er66t56fi06usmjxtetk.png)

- Создают запрос на слияние
![create pull request](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/m1d2x2ee798qr9bnk872.png)

- Проверяете. Оставляете комментарии либо ко всему заданию целиком, либо к его отдельным частям.
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/rsxi53u1d3awekrmntwk.png)
![code review](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7w1p8fxw5zqhwlww8968.png)

- Создаются релизы. Готовые DLL или ещё что берётся из релизов и подключается в основной проект.
![realese](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hzydena4l48npmjir17a.png)

- В каждой команде ведётся техдокументация.
![documentation](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/0sggujdvog8bdxwtp0dv.png)

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

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

##### Минусы:

- Нужно создавать отдельный аккаунт для организации
- Нужно объяснить как работать с ветками и следить, чтобы пушили в нужную ветку.
- Нужно объяснять что такое релиз, как происходит версионирование.
- Нужно объяснять как пишется и для чего нужна техдокументация.

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

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