В статье «4 причины, почему веб-сервис GitHub нужно использовать при обучении студентов программированию» я кратко рассказал о том, для чего я приучаю студентов именно к этому сервису. Теперь же мы посмотрим на GitHub как на инструмент, который в своей работе часто используют программисты.
Кейс, связанный с форками (с «ответвлениями» в череде изменений какого-либо проекта)
Начну с того, что репозитории с заданиями можно создавать в своем аккаунте, не добавляя туда учеников. Это делается так:
- Создаете репозиторий с названием задания;
- Затем добавляете это задание в README.md (первом файле, который нужно читать, когда получаете доступ к проекту на GitHub) и пишете ученикам подробную инструкцию о том, что и как им нужно будет сделать. При этом обязательно обращайте внимание, как именно вы создаете запрос на слияние (pull request) с вашим исходным репозиторием (подробнее с этим вы можете ознакомиться тут: ДЗ по Qt);
- Далее сообщаете студентам задание, отправляя им ссылку на нужный репозиторий, и ждете его выполнения, а именно когда будет создан запрос на слияние;
- А потом проверяете, как ученики справились с задачей, и оставляете комментарии либо ко всей работе целиком, либо к ее отдельным частям.
Плюсы и минусы данного кейса
Плюсы:
- Студентов не нужно добавлять в аккаунт организации или делать соразработчиками репозитория;
- Задания можно рассылать любому количеству учеников из разных групп и разных учебных заведений.
Минусы:
- Необходимо следить за тем, чтобы студенты не применили свои изменения в основном репозитории;
- Нужно подробно им объяснять, что такое форк и как делать запрос на слияние (чаще всего именно эти моменты вызывают затруднения у учащихся).
С точки зрения преподавателя отмечу, что бывает сложно отследить, когда ученики ошибаются и делают слияние кода. Тогда в репозитории отображается не только задание, но и код решения.
Конечно, вы можете добавить под каждого студента свою ветку. Но это может привести к большим временным затратам.
Далее рассмотрим ситуацию, когда над проектом трудится целая команда людей, но при этом не создается огромное количество репозиториев и веток:
- В этом случае понадобится аккаунт организации, в который будут добавлены студенты;
- Затем нужно будет создать репозиторий и в README.md добавить текст задания (не забудьте, что предварительно репозиторий надо наполнить файлами, необходимыми для выполнения этого задания);
- Далее создаются ветви, где будет вестись основная разработка, проверка всех фич и устранение багов;
- Студенты, получив задания (через issues или другие сервисы вроде Kanban или Scrum), делают ответвления от последнего коммита (то есть создают «изолированную» копию для написания, изменения или дополнения программы), решают поставленные задачи и создают запрос на слияние;
- После этого вы проверяете, как ученики справились с работой, и оставляете комментарии или к ней в целом, или к отдельным ее частям.
Плюсы и минусы данного кейса
Плюсы:
- Данный кейс моделирует более-менее реальный проект разработки ПО;
- Можно назначать студентов ревьюерами даже преподавательского кода. Я, например, специально делаю в коде явные и неявные ошибки, чтобы ученики находили их и исправляли.
Минусы:
- Нужно создавать отдельный аккаунт для организации;
- Подробно объяснять учащимся, как работать с ветками.
И последний интересный кейс, рассказывающий про командную работу с несколькими репозиториями.
Это наиболее реальный проект разработки ПО из всех вышеперечисленных, когда в рамках реализации одной программы возникают подпроекты, и над ними трудятся разные команды в разных репозиториях. В этой ситуации часть действий повторяется из предыдущего кейса:
- Создается аккаунт организации, в который добавляются студенты;
- Затем создается репозиторий, и в README.md добавляется текст задания. Не забудьте, что предварительно репозиторий нужно будет наполнить файлами, которые требуются для выполнения этого задания. После, как и в вышеуказанном случае, создаются ветки (dev или develop);
- Ученики, получив задание, клонируют репозиторий себе на локальные машины (то есть к себе на компьютеры);
- Вслед за этим выявляются подпроекты, для каждого из которых создаются команды и репозиторий с предварительным наполнением. Задания можно выдавать как через issues, так и через сервисы Kanban или Scrum;
- Далее студенты создают запрос на слияние;
- А вы проверяете, как ученики справились с работой, и оставляете комментарий или к ней целиком, или к отдельным ее частям;
- Следующий этап — создание релизов. Готовые DLL (динамические библиотеки, позволяющие многократное использование различных программных приложений), которые берутся из этих релизов, подключаются в основной проект;
- И чтобы при подключении и использовании DLL не было проблем, в каждой команде обязательно ведется техдокументация.
Сразу расскажу о нескольких полезных моментах, которые помогут при решении данного кейса:
- Вы можете связать репозиторий с Kanban- или Scrum-сервисом, чтобы выдача заданий фиксировалась в карточках на досках;
- И создавать не отдельные репозитории для каждого подпроекта, а использовать git submodules (подмодули).
Плюсы и минусы кейса
Плюсы:
- Как уже отметил ранее, это наиболее реальный проект разработки ПО;
- Можно назначать учащихся в качестве ревьюеров даже преподавательского кода. Опять-таки в этом случае я намеренно делаю в коде явные и неявные ошибки, чтобы студенты могли потренировать свое внимание;
- Развивается навык работы в команде, когда ученики совместно разрабатывают один большой проект.
Минусы:
- Нужно создавать отдельный аккаунт для организации;
- Следить, как студенты работают с ветками;
- Объяснять им, что такое релиз и как происходит версионирование (отделение версий ПО друг от друга);
- Подробно рассказывать, как и для чего пишется техдокументация.
Автор статьи: Андрей Старинин
