Введение
Вы можете использовать репозитории GitHub , проблемы, проекты и другие средства для планирования и отслеживания работы, будь то работа с отдельным проектом или кроссфункциональными командами.
В этом руководстве вы узнаете, как создать и настроить репозиторий для совместной работы с группой людей, создать шаблоны проблем и формы, открыть списки задач и использовать списки задач для разбиения работы, а также установить project (классическая модель) для организации и отслеживания проблем.
Создание репозитория
При запуске нового проекта, инициативы или компонента в первую очередь создается репозиторий. Репозитории содержат все файлы проекта и служат местом для совместной работы с другими пользователями и управления работой. Дополнительные сведения см. в разделе Создание репозитория.
Репозитории можно настраивать для разных целей в зависимости от ваших потребностей. Вот несколько основных способов применения:
- Репозитории продуктов: крупные организации, которые отслеживают свою работу и цели по отдельным продуктам, могут иметь один или несколько репозиториев, содержащих код и другие файлы. Такие репозитории также можно использовать для документации, отчетов о работоспособности продукта или планов по его развитию.
- Репозитории проектов: репозитории можно создавать как для личных проектов, так и для проектов, над которым вы работаете вместе с другими пользователями. Организации, которая отслеживает работу по краткосрочным инициативам или проектам, например консалтинговой компании, необходимо получать отчеты о работоспособности проекта и перераспределять людей между разными проектами с учетом навыков и потребностей. Код проекта часто содержится в одном репозитории.
- Репозитории команд: в организации, где над проектами работают команды, такие как команда средств разработки, код может быть распределен между несколькими репозиториями, созданными для разных работ, которые им нужно отслеживать. В этом случае может быть удобнее создать для каждой команды отдельный репозиторий как единое место для отслеживания всех работ, в которых она участвует.
- Личные репозитории: личный репозиторий позволяет отслеживать все работы в одном месте, планировать будущие задачи и даже добавлять заметки или информацию, которую вы хотите сохранить. Сюда можно добавлять участников совместной работы, чтобы предоставить доступ к информации другим пользователям.
Если вам необходимы разные разрешения на доступ к исходному коду или вы хотите отслеживать проблемы и обсуждения, можно создать несколько отдельных репозиториев. Дополнительные сведения см. в разделе Создание репозитория только для проблем.
В следующих примерах в этом руководстве мы будем использовать пример репозитория под названием Project Octocat.
Передача данных о репозитории
Для репозитория можно создать файл README.md, чтобы рассказать о своей команде или проекте или сообщить важные сведения о репозитории. Зачастую README — первое, что видит посетитель репозитория, поэтому здесь же можно указать, каким образом пользователи или участники могут приступить к работе над проектом и как связаться с командой. Дополнительные сведения см. в разделе О файлах README.
Кроме того, можно создать файл CONTRIBUTING.md и добавить в него инструкции по участию в работе и взаимодействию с командой или проектом, например, информацию о том, как подать запрос на устранение ошибки или на доработку. Дополнительные сведения см. в разделе Создание рекомендаций для участников репозитория.
Пример файла README
Создадим файл README.md с информацией о нашем новом проекте — Project Octocat.
Создание шаблонов проблем
Проблемы можно использовать для отслеживания различных типов работ вашей междисциплинарной команды или проекта, а также для сбора соответствующей информации за пределами проектами. Приведем несколько распространенных вариантов использования проблем.
- Отслеживание выпусков: проблему можно использовать для отслеживания хода выполнения выпуска или этапов запуска.
- Крупные инициативы: проблему можно использовать для отслеживания хода выполнения крупной инициативы или проекта, которые затем сопоставляются с проблемами поменьше.
- Запросы компонентов: ваша команда или пользователи могут создавать проблемы для запроса доработки того или иного продукта или проекта.
- Ошибки: ваша команда или пользователи могут создавать проблемы для сообщения об ошибке.
В зависимости от типа репозитория и проекта, над которым вы работаете, одним типам проблем можно присваивать более высокий приоритет, чем другим. После определения наиболее распространенных типов проблем для вашей команды можно создать шаблоны проблем и forms для репозитория. Шаблоны проблем и forms позволяют создавать стандартный список шаблонов, которые участник может выбрать при открытии проблемы в репозитории. Дополнительные сведения см. в разделе Настройка шаблонов проблем для репозитория.
Пример шаблона проблем
Ниже мы создадим шаблон проблемы для сообщения об ошибке в Project Octocat.
Теперь, когда мы создали шаблон проблемы с сообщением об ошибке, его можно будет выбрать при создании новой проблемы в Project Octocat.
Открытие проблем и использование списков задач для отслеживания работы
Для организации и отслеживания работы можно создавать проблемы. Дополнительные сведения см. в разделе Создание проблемы.
Пример проблемы
Приведем пример проблемы, созданной для крупной иницбиативы (внешний интерфейс) в Project Octocat.
Пример списка задач
Списки задач можно использовать для деления больших проблем на небольшие задачи и отслеживания проблем в рамках более крупной цели. Дополнительные сведения см. в разделе "Сведения о списках задач".
Ниже мы добавили список задач в проблему Project Octocat, разделив ее на проблемы поменьше.
Принятие решений в команде
Проблемы и обсуждения можно использовать для взаимодействия и командного принятия решений по плановым доработкам или приоритетам в рамках проекта. Проблемы полезно создавать для обсуждения определенных деталей, таких как отчеты об ошибках или производительности, планы на следующий квартал или разработка новой инициативы. Обсуждения полезны для открытого мозгового штурма или обратной связи за пределами базы кода и в репозиториях. Дополнительные сведения см. в разделе Взаимодействие с GitHub.
Кроме того, в рамках команды с помощью проблем можно сообщать об изменениях в повседневных задачах, чтобы все были в курсе состояния работы. Например, можно создать проблему для большого компонента, над которым работают несколько человек, что позволит каждому участнику группы добавлять обновления с указанием состояния и открывать вопросы в этой проблеме.
Пример проблемы с участниками проектами
Приведем пример того, как участники одного проекта сообщают об изменении состояния работы в проблеме Project Octocat.
Использование меток для выделения целей и состояния проекта
Для репозитория можно создавать метки, позволяющие классифицировать проблемы, запросы на вытягивание и обсуждения. Кроме того, в GitHub предусмотрены метки по умолчанию для каждого нового репозитория, которые можно изменять или удалять. Метки помогают отслеживать цели проектов, ошибки, типы работ и состояния проблемы.
Дополнительные сведения см. в разделе Управление метками.
Метку, созданную в репозитории, можно впоследствии применять к любой проблеме, запросу на вытягивание или обсуждению в этом репозитории. Фильтрация проблем и запросов на вытягивание по меткам позволит найти все соответствующие работы. Например, чтобы найти в проекте все ошибки внешнего интерфейса, отфильтруйте проблемы с метками front-end и bug. Дополнительные сведения см. в разделе Фильтрация и поиск проблем и запросов на вытягивание.
Пример метки
Ниже приведен пример метки front-end, которую мы создали и добавили в проблему.
Добавление проблем в project (классическая модель)
Вы можете использовать проекты на GitHub для планирования и отслеживания работы для вашей команды. Проект — это настраиваемая электронная таблица, которая интегрируется с вашими проблемами и запросами на вытягивание в GitHub и автоматически обновляет сведения в GitHub. Макет можно настраивать, фильтруя, сортируя и группируя проблемы и запросы на вытягивание. Сведения о начале работы с проектами см. в разделе "Краткое руководство по Projects (beta)".
Пример проекта
Ниже показан табличный макет из примера проекта, заполненный созданными нами проблемами Project Octocat.
Этот же проект можно открыть как доску.
Вы можете также использовать существующие projects (classic) на GitHub для планирования и отслеживания своей работы и работы вашей команды. Проекты (классическая модель) состоят из проблем, запросов на вытягивание и заметок, распределенных в виде карточек между столбцами по вашему выбору. Вы можете создать проекты (классическая модель) для работы функций, высокоуровневых схем или даже контрольных списков выпуска. Дополнительные сведения см. в разделе Сведения о projects (classic).
Пример Project (классическая модель)
Ниже приведено значение project (классическая модель) для нашего примера Project Octocat с созданной проблемой, а более мелкие проблемы, в которые мы сломали его, добавили в него.
Следующие шаги
Вы узнали о предлагаемых инструментах GitHub для планирования и отслеживания работы, а также о том, как настраивать репозиторий для междисциплинарной команды или проекта. Вот несколько полезных ресурсов по дальнейшей настройке репозитория и организации вашей работы.
- "Сведения о репозиториях" для получения дополнительных знаний о создании репозиториев
- "Отслеживание результатов устранения неполадок" для получения дополнительных возможностей для создания и управления проблемами
- "Сведения о шаблонах проблем и запросов на вытягивание" для получения дополнительных знаний о шаблонах проблем
- AutoTITLE для обучения созданию, редактированию и удалению меток
- "[AUTOTITLE" для получения дополнительных знаний о списках задач -Сведения о списках задач](/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) для получения дополнительных данных о проектах
- "[AUTOTITLE" для обучения настройке представлений для проектов - "Изменение макета представления](/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards)" для обучения управлению проекты (классическая модель)