Функции 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.
Предполагается, что вы вели разработку в своей, публично доступной копии репозитория — форке. Публичность нужна для возможности улучшения вашей копии другими пользователями перед окончательным включением ваших изменений в центральный репозиторий.
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.
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.»
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
Для приватных тикетов
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
Оценка по степени влияния
Оценка по степени ущерба
Оценка по размеру
Оценка по критерию MoSCoW
Оценка по частоте
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Project planning for developers
Create issues, break them into tasks, track relationships, add custom fields, and have conversations. Visualize large projects as spreadsheets or boards, and automate everything with code.
Bored of boards?
Switch to tables.
Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests. Tailor them to your needs with custom fields and saved views.
Break issues into actionable tasks
Tackle complex issues with task lists and track their status with new progress indicators. Convert tasks into their own issues and navigate your work hierarchy.
Move conversations forward
Express ideas with GitHub Flavored Markdown, mention contributors, react with emoji, clarify with attachments, and see references from commits, PRs, releases, and deploys. Coordinate by assigning contributors and teams, or by adding them to milestones and projects. All in a single timeline.
Upload and attach videos to comments
Dive into work faster with issue forms and templates
Upload and attach videos to comments
Dive into work faster with issue forms and templates
Create views
for how you work
Save views for sprints, backlogs, teams, or releases. Rank, group, sort, and filter issues to suit the occasion. Choose between tables, boards, and timelines (coming soon).
Work at keyboard speed
No mouse? No problem. Every action you can take with the mouse has a keyboard shortcut or command. Filter, sort, group, and assign issues. Your hands never leave the keyboard.
Extend issues
with custom fields
Track metadata like iterations, priority, story points, dates, notes, and links. Add custom fields to project tables and edit from the issue sidebar.
Now with iteration cycle planning
Tailor reports from any field
Make any field reportable. Track the progress of your current iteration cycle, milestone, or visualize bottlenecks and issues blocking the team with the new project insights.
Manage work automatically
Accelerate your project planning with automations. Automatically triage issues, set values for custom fields, react to changes, or schedule something. You can even tee them up to run an Action.
Issues, wherever you look
Issues can be viewed, created, and managed in your browser, your favorite terminal, or on your phone or iPad.
GitHub CLI
View, update, and create issues without ever leaving your terminal.
GitHub Mobile
Create and manage issues on the go with our native iOS and Android mobile apps.
“ The new planning and tracking functionality keeps my project management close to my code. I no longer find myself needing to reach for spreadsheets or 3P tools which go stale instantly.
Frequently
asked questions
Why GitHub Issues?
We all need a way to plan our work, track issues, and talk about the things we build. Our answer to this universal question is GitHub Issues, and it’s built-in to every repository. GitHub’s issue tracking is special because of our focus on simplicity, references, and elegant formatting.
With GitHub Issues you can express ideas with GitHub Flavored Markdown, assign and mention contributors, react with emoji, clarify with attachments and videos, plus reference code like commits, pull requests, and deploys. With task lists you can break big issues into tasks, and then further organize your work with milestones and labels, and track relationships and dependencies.
We built GitHub issues for developers. It is simple, flexible, and powerful.
Why project tables and boards?
As teams and projects grow, how we work evolves. Tools that hard-code a specific methodology are too specific and rigid to flex to whatever the moment demands. Often, we find ourselves creating a spreadsheet or pulling out a notepad, just to have the space to think. But then our planning is disconnected from where the work happens and quickly goes stale.
The new Projects connect your planning directly to the work your teams are doing, and flexibly adapt to whatever your team needs at any point. Built like a spreadsheet, project tables give you a live canvas to filter, sort, and group issues and pull requests. You can use it, or the accompanying project board, along with custom fields, to track a sprint, plan a feature, or manage a large-scale release.
I am in the Beta, where do I share feedback?
How much will the new GitHub Issues cost?
Our plan is to continue to bundle GitHub Issues and its new project planning capabilities in our Free, Pro, Team, and Enterprise plans at no additional cost.
Will the Beta be available in GitHub Enterprise Server?
GitHub Enterprise Server support follows our normal cadence of one to two quarters before we enable the functionality on-premises.
How does this co-exist with other features like the existing kanban boards?
Once the Beta is enabled on your account, the organization’s projects page will display both projects (classic kanban) and the new beta projects (with table and custom field) side by side. They will coexist through the beta period, with classic projects automatically updating to leverage the new features prior to general availability.
It is important to note that at this time there are no migration tools available, both from existing projects or other planning and tracking tools.
How can I create a new project at the repo level?
Repo level projects are not currently supported, but is high on our roadmap and coming soon.
What is on the roadmap for the new GitHub Issues?
We are really excited to start this journey with all of you.
Our roadmap towards general availability (GA) will evolve, but expect improvements to the core flows and new functionality to be continuously added. Top features include:
Термины Гита и Гитхаба #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
На Гитхабе есть объяснение основных терминов, поэтому можно что-то ещё оттуда взять, дополнить.
