github что такое issue
Mastering Issues
Issues are a great way to keep track of tasks, enhancements, and bugs for your projects. They’re kind of like email—except they can be shared and discussed with the rest of your team. Most software projects have a bug tracker of some kind. GitHub’s tracker is called Issues, and has its own section in every repository.
For example, let’s take a look at Bootstrap’s Issues section:
GitHub’s issue tracking is special because of our focus on collaboration, references, and excellent text formatting. A typical issue on GitHub looks a bit like this:
A title and description describe what the issue is all about.
Color-coded labels help you categorize and filter your issues (just like labels in email).
A milestone acts like a container for issues. This is useful for associating issues with specific features or project phases (e.g. Weekly Sprint 9/5-9/16 or Shipping 1.0).
One assignee is responsible for working on the issue at any given time.
Comments allow anyone with access to the repository to provide feedback.
Milestones, Labels, and Assignees
Once you’ve collected a lot of issues, you may find it hard to find the ones you care about. Milestones, labels, and assignees are great features to filter and categorize issues.
You can change or add a milestone, an assignee, and labels by clicking their corresponding gears in the sidebar on the right.
If you don’t see edit buttons, that’s because you don’t have permission to edit the issue. You can ask the repository owner to add you as a collaborator to get access.
Milestones
Milestones are groups of issues that correspond to a project, feature, or time period. People use them in many different ways in software development. Some examples of milestones on GitHub include:
Beta Launch — File bugs that you need to fix before you can launch the beta of your project. It’s a great way to make sure you aren’t missing anything.
October Sprint — File issues that you’d like to work on in October. A great way to focus your efforts when there’s a lot to do.
Redesign — File issues related to redesigning your project. A great way to collect ideas on what to work on.
Labels
Labels are a great way to organize different types of issues. Issues can have as many labels as you want, and you can filter by one or many labels at once.
Assignees
Each issue can have an assignee — one person that’s responsible for moving the issue forward. Assignees are selected the same way milestones are, through the grey bar at the top of the issue.
Notifications, @mentions, and References
By using @mentions and references inside of Issues, you can notify other GitHub users & teams, and cross-connect issues to each other. These provide a flexible way to get the right people involved to resolve issues effectively, and are easy to learn and use. They work across all text fields on GitHub — they’re a part of our text formatting syntax called GitHub Flavored Markdown.
If you’d like to learn more, have a look at Mastering Markdown.
Notifications
Notifications are GitHub’s way to keep up to date with your Issues. You can use them to find out about new issues on repositories, or just to know when someone needs your input to move forward on an issue.
There are two ways to receive notifications: via email, and via the web. You can configure how you receive notifications in your settings. If you plan on receiving a lot of notifications, we like to recommend that you receive web + email notifications for Participating and web notifications for Watching.
With these settings, you receive emails when people specifically mention you, then visit the web-based interface to keep up to date with repositories you’re interested in.
Muted threads won’t show up as unread again until you are specifically @mentioned again. This makes muting a great strategy for threads that you have little interest in (perhaps a sub-system that you aren’t familiar with). If you mark an issue as read, it will stay that way until someone comments on the thread again.
GitHub also syncs read/unread status for email notifications — if you read a notification in your email client, it will be marked as read in the web-based interface (make sure you allow your email client to display images if you’d like this functionality).
@mentions
@mentions are the way that we reference other GitHub users inside of GitHub Issues. Inside of the description or any comment of the issue, include the @username of another GitHub user to send them a notification. This works very similar to how Twitter uses @mentions.
We like to use the /cc syntax (an abbreviation for carbon copy) to include people in issues:
It looks like the new widget form is broken on Safari. When I try and create the widget, Safari crashes. This is reproducible on 10.8, but not 10.9. Maybe a browser bug?
This works great if you know the specific users to include, but many times we’re working across teams and don’t really know who might be able to help us. @mentions also work for Teams within your GitHub organization. If you create a Team called browser-bugs under the @acmeinc organization, you can reference the team with @mentions:
This will send notifications to every member of the browser-bugs team.
References
Often times issues are dependent on other issues, or at least relate to them and you’d like to connect the two. You can reference issues by typing in a hashtag plus the issue number.
Hey @kneath, I think the problem started in #42
When you do this, we’ll create an event inside of issue #42 that looks something like this:
One of the more interesting ways to use GitHub Issues is to reference issues directly from commits. Include the issue number inside of the commit message.
By prefacing your commits with “Fixes”, “Fixed”, “Fix”, “Closes”, “Closed”, or “Close” when the commit is merged into main, it will also automatically close the issue.
References make it possible to deeply connect the work being done with the bug being tracked, and are a great way to add visibility into the history of your project.
Search
At the very top of each page is a search box that lets you search through issues.
You can scope search results by:
Our Help article on searching Issues can show you other ways to search: using created/updated dates, labels, authors, comment counts, by repository owner, and more.
Overviews & Reports
Outside of the Issues section, there are two other pages that help summarize what’s going on with Issues across your repository and across all of your repositories.
The Issue Dashboard
If you’re looking for a broader listing of all of your issues across many projects, the Issues Dashboard can be a great tool. The dashboard works very similar to the issues section, but collects issues differently:
If you use organizations, each one has its own Issues dashboard that separates out Issues within the organization.
Pulse
Underneath each repository is a section called Pulse — Pulse is a snapshot of everything that’s happened in the repository in the past week (or day, or past 3 months, etc).
It’s a great way to catch up with repositories when you’ve been away and don’t want the granularity notifications offer when watching a repository.
Other Uses for Issues
Issues are great for tracking all kinds of things — and GitHub is a great place to easily share and collaborate on your issues. Here’s some of our favorites:
Now congratulate yourself — that was a lot to read! Issue management is one of the most powerful tools at any developer’s disposal. I guess all that’s left is to actually fix the bugs now.
Last updated July 24, 2020
GitHub is the best way to build and ship software.
Powerful collaboration, code review, and code management for open source and private projects.
Термины Гита и Гитхаба #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 : 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). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Запустить разбор можно:
Знакомство с 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 предлагает множество инструментов для работы с вашим кодом.