Перейти к основному содержимому

Лабораторная работа №4. GitHub: совместная работа, Pull Requests, Issues, Projects и дополнительные возможности GitHub

Тема лабораторной работы: Работа с GitHub для командной разработки: Pull Requests, Issues, Projects и другие инструменты GitHub.

Цель работы: Научиться использовать возможности Git и GitHub для командной разработки, включая совместную работу в парах, работу с ветками (branching), Pull Requests, управление задачами через Issues и Projects, а также использование GitHub Wiki для документации проекта.

Оборудование и программное обеспечение:

  • Компьютер с установленной операционной системой (Windows, macOS, Linux).
  • Установленный Git (https://git-scm.com/downloads).
  • Учётная запись на GitHub (https://github.com/).
  • Текстовый редактор или IDE (например, Visual Studio Code).
  • Доступ в интернет.
  • Партнёр для выполнения работы в паре.

Задачи лабораторной работы​

  1. Настройка удалённого репозитория на GitHub.
  2. Совместная работа в паре через форки и Pull Requests.
  3. Работа с ветками для управления разработкой.
  4. Управление задачами через Issues и Projects.
  5. Документирование проекта с помощью GitHub Wiki.
  6. Работа с релизами и тегами.
  7. Разрешение конфликтов слияния (merge conflicts).

Теоретическое обоснование основных понятий​

  1. GitHub — это облачная платформа для размещения репозиториев, которая предоставляет возможность использовать Git для контроля версий. GitHub помогает организовать командную работу над проектами, обеспечивая совместный доступ к коду, задачи и документации.

  2. Репозиторий — это хранилище, в котором хранится код и история изменений проекта. Он может быть как локальным, так и удалённым (на GitHub).

  3. Ветвление (Branching) — механизм, позволяющий создавать параллельные версии кода для разработки новых функций или исправления ошибок, не влияя на основную версию (обычно ветку master или main).

  4. Pull Request (PR) — это запрос на внесение изменений в основной кодовой базой проекта, который позволяет другим участникам проекта просмотреть, обсудить и принять или отклонить эти изменения.

  5. Issues — это инструмент для управления задачами и отслеживания проблем, которые нужно решить в проекте.

  6. Projects — это инструмент для планирования и управления задачами на уровне проекта. Обычно Projects отображает задачи в виде канбан-доски.

  7. Wiki — это встроенная в GitHub система для создания документации, которая может быть обновляема сообществом проекта.

  8. Merge Conflicts — конфликт слияния, который возникает, когда изменения, внесённые в разных ветках, конфликтуют между собой и требуют ручного разрешения.

Ход выполнения работы​

Шаг 1. Создание удалённого репозитория на GitHub​

  1. Один из участников пары создаёт новый репозиторий на GitHub, добавляет базовый файл README.md и настраивает доступ для второго участника (через Settings -> Collaborators).

Теория:

  • README.md — это файл, содержащий основную информацию о проекте, его цели, инструкции по установке и использованию.
  • Добавление участников проекта в качестве Collaborators позволяет другим людям вносить изменения в репозиторий напрямую, что важно для командной работы.

Шаг 2. Клонирование репозитория​

  1. Оба участника клонируют удалённый репозиторий на свои локальные машины для дальнейшей работы: 
    git clone https://github.com/yourusername/repository-name.git

Теория:

  • Клонирование (clone) — это создание локальной копии удалённого репозитория. Вся работа в локальной копии будет синхронизироваться с удалённым репозиторием через команды push (отправка изменений) и pull (получение изменений).

Шаг 3. Работа с ветками (Branching)​

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

    git checkout -b feature/new-feature

  2. В этой ветке каждый участник выполняет свою часть работы.

Теория:

  • Ветвление (Branching) позволяет параллельно работать над разными задачами (например, разработка новой функциональности или исправление багов), не влияя на основную ветку (master или main). Это важно для работы в команде, чтобы избежать конфликтов и сбоев.

Шаг 4. Работа с Pull Requests (PR)​

  1. После выполнения задачи участник отправляет свою ветку в удалённый репозиторий:

    git push origin feature/new-feature

  2. Затем создаёт Pull Request через интерфейс GitHub, чтобы другой участник мог провести ревью изменений.

Теория:

  • Pull Request — это запрос на слияние изменений, который позволяет проводить код-ревью и обсуждать изменения до их внесения в основную ветку. PR также помогает отслеживать историю внесённых изменений и упрощает процесс командной работы.

Шаг 5. Работа с Issues​

  1. Один из участников создаёт Issue для задачи, над которой будет работать второй участник. Например, "Реализовать авторизацию пользователя".

  2. Второй участник берёт Issue себе и начинает работать над задачей в отдельной ветке.

Теория:

  • Issues помогают отслеживать задачи, которые необходимо выполнить в проекте. Это может быть реализация новой функциональности, исправление ошибки или обсуждение улучшений. Каждый Issue может быть назначен на конкретного участника и содержать метки (labels) для классификации.

Шаг 6. Работа с Projects​

  1. Создайте проект (Project) на GitHub, используя канбан-доску для организации задач. Добавьте несколько колонок, например, "To Do", "In Progress", "Done".

  2. Перетащите Issue в соответствующую колонку, когда работа над ним начинается или заканчивается.

Теория:

  • Projects — это инструмент для организации задач с помощью визуальной доски, которая помогает отслеживать прогресс по проекту. Projects можно использовать для распределения задач между участниками команды и контроля выполнения.

Шаг 7. Работа с GitHub Wiki​

  1. Добавьте в Wiki описание проекта, его структуру, цели и инструкции по установке.

  2. Один из участников должен задокументировать API проекта, если таковое имеется, или дать общие инструкции по использованию приложения.

Теория:

  • Wiki на GitHub — это инструмент для создания документации проекта. Она важна для командной работы, особенно в больших проектах, где требуется поддерживать подробную информацию о проекте, его структуре, API, инструкции по установке и использованию.

Шаг 8. Разрешение конфликтов при слиянии (Merge Conflicts)​

  1. Смоделируйте ситуацию, при которой оба участника изменяют один и тот же файл в разных ветках.

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

Теория:

  • Конфликт слияния возникает, когда два или более участников вносят изменения в одну и ту же часть кода. Git не может автоматически объединить эти изменения, поэтому разработчики должны вручную выбрать, какие изменения оставить. Конфликты чаще всего возникают при одновременной работе в одной ветке, что делает ветвление важным элементом командной разработки.

Шаг 9. Создание релизов и тегов​

  1. После завершения работы создайте первый релиз (например, версия v1.0).

  2. Назначьте тег для версии:

    git tag -a v1.0 -m "Первый релиз проекта"
    git push origin v1.0

Теория:

  • Релизы позволяют сохранить состояние проекта на определённом этапе, обычно для развертывания или публичного выпуска. Теги используются для маркировки определённых версий в истории коммитов. Это удобно для обозначения стабильных версий и для дальнейшего отслеживания истории проекта.

Индивидуальные задания по работе с GitHub в паре и разработке на языке C#​

Задания разработаны для выполнения в паре, чтобы студенты могли использовать возможности командной разработки с GitHub, такие как ветвление, Pull Requests, Issues, Projects и другие инструменты. Основной язык разработки — C# с использованием ASP.NET для веб-приложений или консольных приложений.

Общие требования ко всем вариантам​

  1. Работа в паре: Один студент отвечает за фронтенд (например, Razor Pages, ASP.NET MVC), второй — за бэкенд (API, бизнес-логика, работа с базой данных).
  2. Создать репозиторий на GitHub и использовать его для контроля версий.
  3. Организовать работу с ветками: каждый работает в своей ветке, после чего изменения сливаются через Pull Requests.
  4. Управлять проектом через Issues и Projects.
  5. Обеспечить документирование через GitHub Wiki.
  6. Настроить автоматизацию сборки или тестирования с помощью GitHub Actions (по желанию).

Вариант 1: Система управления событиями (Event Management System)​

Описание проекта: Создать систему для управления событиями, где пользователи могут регистрироваться на мероприятия, а организаторы могут добавлять новые события и управлять регистрациями.

  • Функциональные требования:
    1. Студент, отвечающий за фронтенд, реализует веб-интерфейс для просмотра событий, регистрации пользователей на мероприятия и управления событиями.
    2. Студент, отвечающий за бэкенд, разрабатывает API для управления событиями (CRUD операции) и регистрацией участников.
    3. Информация о событиях и участниках хранится в базе данных (SQLite или MS SQL).
    4. Валидация данных при создании события и регистрации на него.

Задачи:

  1. Создать веб-интерфейс для добавления и редактирования событий.
  2. Реализовать систему регистрации участников на события.
  3. Бэкенд: Реализовать API для управления событиями и участниками.
  4. Фронтенд: Подключить интерфейс к API и реализовать взаимодействие с пользователем.
  5. Использовать GitHub Issues для разделения задач между студентами и GitHub Projects для отслеживания прогресса.

Вариант 2: Интернет-магазин (Online Store)​

Описание проекта: Разработать веб-приложение для интернет-магазина, которое позволяет пользователям просматривать товары, добавлять их в корзину и оформлять заказы. Администратор может управлять товарами.

  • Функциональные требования:
    1. Студент, отвечающий за фронтенд, создаёт страницы для отображения каталога товаров, корзины и оформления заказа.
    2. Студент, отвечающий за бэкенд, разрабатывает API для управления товарами, корзиной и заказами, а также для управления пользователями (администраторы и клиенты).
    3. Информация о товарах, заказах и пользователях хранится в базе данных (SQLite или MS SQL).
    4. Администратор может добавлять/редактировать товары, а пользователи — оформлять заказы.

Задачи:

  1. Фронтенд: Реализовать страницу каталога товаров с возможностью добавления в корзину.
  2. Бэкенд: Разработать API для управления товарами и корзиной.
  3. Фронтенд: Разработать интерфейс для оформления заказа.
  4. Бэкенд: Реализовать систему управления заказами и интеграцию с базой данных.
  5. Использовать GitHub Wiki для описания структуры API и базы данных.

Вариант 3: Приложение для бронирования услуг (Service Booking System)​

Описание проекта: Разработать систему для бронирования различных услуг (например, бронирование времени для стрижки, медицинских консультаций и т.д.). Пользователи могут бронировать услуги, а администраторы — управлять расписанием и доступными услугами.

  • Функциональные требования:
    1. Студент, отвечающий за фронтенд, реализует веб-интерфейс для бронирования услуг, просмотра расписания и управления личными бронированиями.
    2. Студент, отвечающий за бэкенд, разрабатывает API для управления расписанием, бронированиями и услугами.
    3. Система должна поддерживать различные виды услуг и ограничение на время бронирования.
    4. Информация о бронированиях и услугах хранится в базе данных (SQLite или MS SQL).

Задачи:

  1. Бэкенд: Создать API для управления услугами и расписанием.
  2. Фронтенд: Разработать интерфейс для выбора услуги и времени бронирования.
  3. Бэкенд: Реализовать систему управления бронированиями и ограничениями на время.
  4. Фронтенд: Подключить интерфейс к API для взаимодействия с пользователем.
  5. Использовать GitHub Actions для автоматизации тестирования приложения.

Вариант 4: Приложение для учёта сотрудников (Employee Management System)​

Описание проекта: Создать систему для учёта сотрудников в компании, где можно добавлять, редактировать, удалять и просматривать информацию о сотрудниках, их должностях и департаментах.

  • Функциональные требования:
    1. Студент, отвечающий за фронтенд, разрабатывает интерфейс для добавления, редактирования и просмотра информации о сотрудниках.
    2. Студент, отвечающий за бэкенд, разрабатывает API для управления сотрудниками и их департаментами.
    3. Информация о сотрудниках, их должностях и департаментах хранится в базе данных (SQLite или MS SQL).
    4. Реализовать возможность поиска сотрудников по департаменту или должности.

Задачи:

  1. Бэкенд: Создать API для управления данными сотрудников.
  2. Фронтенд: Реализовать интерфейс для добавления и редактирования данных о сотрудниках.
  3. Бэкенд: Реализовать фильтрацию сотрудников по департаменту и должности.
  4. Фронтенд: Подключить фильтрацию и поиск сотрудников через интерфейс.
  5. Использовать GitHub для организации работы (Issues, Projects, Pull Requests).

Вариант 5: Система для проведения опросов (Survey System)​

Описание проекта: Разработать систему для создания и проведения опросов. Пользователи могут участвовать в опросах, а администраторы — создавать и управлять опросами, а также просматривать результаты.

  • Функциональные требования:
    1. Студент, отвечающий за фронтенд, создаёт страницы для создания опросов, участия в них и просмотра результатов.
    2. Студент, отвечающий за бэкенд, разрабатывает API для управления опросами (создание, редактирование, просмотр результатов) и для обработки ответов пользователей.
    3. Информация о вопросах и ответах должна сохраняться в базе данных (SQLite или MS SQL).
    4. Поддержка различных типов вопросов: с одним выбором, с несколькими вариантами ответов, текстовые вопросы.

Задачи:

  1. Бэкенд: Создать API для создания и управления опросами.
  2. Фронтенд: Реализовать интерфейс для создания и участия в опросах.
  3. Бэкенд: Обеспечить сохранение результатов опросов в базу данных.
  4. Фронтенд: Подключить интерфейс для отображения результатов опросов.
  5. Использовать GitHub Wiki для документирования структуры приложения и API.

Общие требования по использованию GitHub​

  1. Issues: Для каждой задачи создаются отдельные Issues. Задачи распределяются между участниками команды, и каждый работает над своими задачами.
  2. Projects: Использовать Projects для отслеживания прогресса по задачам. Создайте канбан-доску с колонками "To Do", "In Progress", "Done".
  3. Pull Requests: Каждый студент работает в своей ветке и отправляет Pull Requests для слияния изменений в основную ветку. Обсуждение и код-ревью перед слиянием.
  4. GitHub Wiki: Документируйте проект с помощью Wiki. Включите описание архитектуры проекта, API, структуры базы данных и инструкции по запуску.
  5. GitHub Actions: Настройте автоматизацию процессов с использованием GitHub Actions. Например, добавьте тестирование или сборку проекта на каждый Pull Request.

Итог​

Каждый вариант предусматривает работу в паре, где один студент отвечает за фронтенд, а второй — за бэкенд. Все проекты требуют активного использования возможностей GitHub для контроля версий, управления задачами, организации командной работы и автоматизации.

Контрольные вопросы​

  1. Для чего используется Pull Request в командной разработке?
  2. Как работают ветки и зачем они нужны при работе над проектом в команде?
  3. В чём преимущество использования Issues и Projects для управления задачами?
  4. Как разрешать конфликты при слиянии веток?
  5. Что такое GitHub Wiki и зачем она нужна в проекте?

Заключение​

В процессе выполнения лабораторной работы студенты осваивают ключевые навыки работы с Git и GitHub для командной разработки, включая создание веток, Pull Requests, управление задачами через Issues и Projects, а также работу с документацией через Wiki. Эти навыки помогут им эффективно взаимодействовать в командах и управлять проектами, обеспечивая надёжный контроль версий и упрощённое управление задачами.