Что такое issue github
Функции GitHub : Issues, Projects, Pull Requests
Здравствуйте! Помогите, пожалуйста, разобраться с такими функциями GitHub как Issues, Projects, Pull Requests. Для чего они нужны и как правильно с ними работать. У меня есть репозиторий, в котором 2 текстовых файла. И к этому репозиторию надо применить эти функции. Заранее, огромное спасибо!
1 ответ 1
Issues — это система учёта ошибок, по-английски bugtracker.
Конечно, она не такая навороченная, как, к примеру Jira. Однако разработчики Github-а считают эту простоту преимуществом благодаря гибкости и отсутствию визуального мусора.
Так как у Github Issues отсутствуют такие важные поля, как «Категория», «Серъёзность», «Статус» и «Компонент», их приходится заменять проставлением различных меток. Вот как это предлагает делать некто Zach Dunn:
Интересной особенность GitHub является то, что нумерация сообщений в Issue Tracker-e является общей с Pull Requests, хотя эти два понятия не пересекаются и находятся в разных категориях.
Более подробно о Github Issues можно прочитать в официальной справке.
Projects — это хранилище заметок. Больше о нём и сказать нечего, кроме упоминания возможности упорядочивать заметки по столбцам (категориям) и строкам. Вот, собственно, и всё. Можете хоть хранить напоминания, хоть организовать доску для канбана.
Pull Requests — это заявка на принятие ваших изменений в центральный репозиторий. Является неотъемлемой частью Github Flow.
Предполагается, что вы вели разработку в своей, публично доступной копии репозитория — форке. Публичность нужна для возможности улучшения вашей копии другими пользователями перед окончательным включением ваших изменений в центральный репозиторий.
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Термины Гита и Гитхаба #234
Comments
meritt commented Apr 23, 2016
Мы для Академии подготовили небольшой список терминов Гита и я хотел бы его внести в словарь. Я не уверен, что все они подойдут, поэтому скажите, что точно надо выкинуть и я оформлю пулреквест. Я предлагаю сделать отдельный файл git.md и туда добавить следующее:
The text was updated successfully, but these errors were encountered:
pepelsbey commented Apr 23, 2016
Обновиться из апстрима
Обновиться из ориджина
Я бы просто «апстрим» и «ориджин» ввёл, как термины. А потом примеры использования.
pepelsbey commented Apr 23, 2016
Код-ревью писал бы через дефис, т.к. есть слово ревью и можно сказать «ревью кода»
pepelsbey commented Apr 23, 2016
Также комит и мёрж. @tachisis, что думаешь?
jucke commented Apr 23, 2016
tachisis commented Apr 23, 2016
@pepelsbey а по какой причине у тебя буква м выпала? Я пишу оба так, как у Леши
pepelsbey commented Apr 23, 2016
@tachisis, ладно «коммит», но вот мёрдж (три согласные подряд) я совсем не могу читать, всё равно «д» выскакивает при произнесении. С ориджином проще, там ридж, а не рдж. Тут приводили в пример Джорджию, но почему-то не убедили.
tachisis commented Apr 23, 2016
Это такая традиция. Но в целом можно и выкинуть д, я чаще встречаю, что все пишут «мержить»
Nakleikoff commented Apr 25, 2016
igoradamenko commented Apr 25, 2016
@Nakleikoff ну тут спорный момент. в этом слове в начале идёт гласная и потому дальше читать легче. попробуйте же прочитать: «смерджить» и «смержить». Второй вариант читается значительно легче, да и даже первый вариант вы будете произносить как второй. «Д» определённо выпадает. Даже гугл об этом говорит:
«смерджить»
Возможно, вы имели в виду: «смержить»
pepelsbey commented Apr 25, 2016 •
Перевес в сторону без «д» в поиске от 2/1 до 3/1.
Гугл ищет слова с «ё» и «е» как два разных, результаты суммировал.
igoradamenko commented Apr 25, 2016
На Гитхабе есть объяснение основных терминов, поэтому можно что-то ещё оттуда взять, дополнить.
meritt commented May 19, 2016
Curiouslynx commented Jul 12, 2018 •
Знакомство с GitHub
Вкратце, это платформа для разработчиков программного обеспечения, основанная на системе контроля версий Git.
Любой разработчик практически каждый день использует GitHub или другие инструменты, основанные на Git. GitHub нужен для размещения вашего кода или для совместной работы над кодом других людей. В этой статье описываются ключевые понятия GitHub и способы использования некоторых функций для улучшения рабочего процесса.
Почему GitHub?
Теперь, когда вы знаете, что такое GitHub, вы можете спросить, почему следует пользоваться именно им?
Да и вообще, GitHub управляется частной компанией, которая получает прибыль от размещения кода людей. И почему нельзя использовать аналогичные платформы,такие как BitBucket или GitLab?
Помимо личных предпочтений и технических характеристик, есть одна важная причина: каждый использует GitHub, поэтому это отличная платформа для нетворкинга.
С развитием Git другие системы контроля версий потеряли свою популярность, потому что большинство пользователей стали использовать только Git. И не с проста. Разработчики GitHub приложили много усилий для того, чтобы он был удобен в использовании и удовлетворял все потребности программистов.
Поэтому сегодня, когда вы просматриваете какую-то библиотеку, вы в 99% случаев найдете ее на GitHub.
Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.
Теперь давайте начнем с важных концепций Git, которые должен знать разработчик.
GitHub Issues
GitHub Issues предоставляют владельцам репозитория возможность организовывать, помечать и связывать вопросы с определенными этапами разработки.
Если создать задачу на проекте другого пользователя, она останется открытой до тех пор пока вы или кто-то другой не решит ее или владелец репозитория просто не закроет ее.
Бывает так, что ответы на ваши вопросы поступают немедленно. А бывает и такое, что задача висит месяцами в ожидании решения. За это время вы получите комментарии других разработчиков и в дальнейшем сможете вернуться к ней, чтобы что-то исправить или улучшить код.
Пишем код вместе
Несколько лет назад логотип GitHub включал слоган “пишем код вместе”. Думаю, понятно, что это значит.
На GitHub вы можете подписаться на профиль интересующего разработчика или репозиторий. Для этого нужно просто кликнуть “follow” на странице пользователя или кликнуть “watch” на репозитории.
В обоих случаях активность будет отображаться на панели инструментов. Благодаря этому вы сможете отслеживать актуальную информацию.
Система “Звезд”
Одной из отличительных особенностей GitHub является система звёзд. Чтобы выразить свой интерес к репозиторию, его нужно отметить звездой. Это можно сделать с помощью кнопки «Star». Это позволит вам отслеживать интересные проекты и находить похожие.
Это также один из самых важных рейтинговых механизмов, поскольку чем больше звезд имеет репозиторий, тем он популярнее. Поэтому в результатах поиска он будет в топовых местах. Крупные проекты могут иметь десятки тысяч звезд.
Также в GitHub есть трендовая страница, на которой представлены репозитории, которые получают наибольшее количество звезд за определенный период времени (за день, неделю, месяц).
Если вы хотите внести свой вклад в уже существующие проекты, в которых у нас нет прав на внесения изменений путем отправки (push) изменений, вы можете создать свое собственное ответвление (“fork”) проекта. Это означает, что GitHub создаст вашу собственную копию проекта, данная копия будет находиться в вашем репозитории и вы сможете легко делать изменения путем отправки (push) изменений. Также другой человек может разветвить ваш репозиторий, внести некоторые изменения, а затем создать запрос на внесение этих изменений.
Иногда человек, который создает новую ветку из вашего репозитория, может и не попросить вас замерджить что-либо. Это возможно, если ему понравился ваш код и он решил добавить что-то поверх него, но не хочет сливать обратно в исходный репозиторий. Благодаря этому он также может исправить ошибку, с которой столкнулся ранее.
Популярный = лучший
Pull Request
В предыдущей части я уже говорил что такое Pull Request. Повторюсь, человек может создать свое собственное ответвление (“fork”) проекта, внести некоторые изменения и затем сделать Pull Request., чтобы вы замерджили эти изменения.
Чем популярнее проект, тем больше PR он будет иметь, как например, проект React:
Как только человек делает Pull Request, он рассматривается основными разработчиками проекта. В зависимости от количества и сложности изменений, которые вы внесли в код, разработчику может потребоваться разное количество времени, чтобы убедиться, что ваши изменения совместимы с проектом.
У проекта может быть четкий график изменений, которые разработчики хотят внедрить. Тогда ваши запросы на внесение изменений в код будут рассмотрены быстро.
Управление проектами
Кроме обратной связи и новых знакомств, GitHub также предоставляет некоторые функции по управлению проектами.
Wiki предназначен для использования в качестве документации для пользователей.Одним из самых впечатляющих видов использования Wiki, которые я видел до сих пор, является язык программирования Go GitHub Wiki.
Сравнение коммитов
GitHub предлагает множество инструментов для работы с вашим кодом.
Подводя итог
Creating an issue
In this article
Issues can be created in a variety of ways, so you can choose the most convenient method for your workflow.
People with read access can create an issue in a repository where issues are enabled. Members of an enterprise with managed users can only make changes in repositories that are part of their enterprise.
Issues can be used to keep track of bugs, enhancements, or other requests. For more information, see «About issues.»
Repository administrators can disable issues for a repository. For more information, see «Disabling issues.»
Creating an issue from a repository
On GitHub.com, navigate to the main page of the repository.
Under your repository name, click
Issues.
Type a title and description for your issue. 
When you’re finished, click Submit new issue.
Creating an issue with GitHub CLI
GitHub CLI is an open source tool for using GitHub from your computer’s command line. When you’re working from the command line, you can use the GitHub CLI to save time and avoid switching context. To learn more about GitHub CLI, see «About GitHub CLI.»
You can also specify assignees, labels, milestones, and projects.
Creating an issue from a comment
You can open a new issue from a comment in an issue or pull request. When you open an issue from a comment, the issue contains a snippet showing where the comment was originally posted.
Creating an issue from code
You can open a new issue from a specific line or lines of code in a file or pull request. When you open an issue from code, the issue contains a snippet showing the line or range of code you chose. You can only open an issue in the same repository where the code is stored.
Creating an issue from discussion
People with triage permission to a repository can create an issue from a discussion.
When you create an issue from a discussion, the contents of the discussion post will be automatically included in the issue body, and any labels will be retained. Creating an issue from a discussion does not convert the discussion to an issue or delete the existing discussion. For more information about GitHub Discussions, see «About discussions.»
Creating an issue from a project board note
If you’re using a project board to track and prioritize your work, you can convert project board notes to issues. For more information, see «About project boards» and «Adding notes to a project board.»
Creating an issue from a task list item
Within an issue, you can use task lists to break work into smaller tasks and track the full set of work to completion. If a task requires further tracking or discussion, you can convert the task to an issue by hovering over the task and clicking
in the upper-right corner of the task. For more information, see «About task lists.»
Creating an issue from a URL query
You can use query parameters to open issues. Query parameters are optional parts of a URL you can customize to share a specific web page view, such as search filter results or an issue template on GitHub. To create your own query parameters, you must match the key and value pair.
Tip: You can also create issue templates that open with default labels, assignees, and an issue title. For more information, see «Using templates to encourage useful issues and pull requests.»
You must have the proper permissions for any action to use the equivalent query parameter. For example, you must have permission to add a label to an issue to use the labels query parameter. For more information, see «Repository roles for an organization.»
If you create an invalid URL using query parameters, or if you don’t have the proper permissions, the URL will return a 404 Not Found error page. If you create a URL that exceeds the server limit, the URL will return a 414 URI Too Long error page.
Creating an issue from a code scanning alert
Note: The tracking of code scanning alerts in issues is in beta and subject to change.
This feature supports running analysis natively using GitHub Actions or externally using existing CI/CD infrastructure, as well as third-party code scanning tools, but not third-party tracking tools.
If you’re using issues to track and prioritize your work, you can use issues to track code scanning alerts.
For more information about creating issues to track code scanning alerts, see «Tracking code scanning alerts in issues using task lists.»