GitHub Issues: Tagging Best Practices — Save Time!
For people who make software, the internet has no shortage of best practice for workflow organization like Git Flow, release versioning, GitHub, etc. When you get to the topic of issue management, the reading material plummets.
At Robin, GitHub issues are the core of just about every action the team takes. Over the past year, we've worked out an internal tagging system that keeps engineering and product efforts organized across repositories on Github. We're sharing the current iteration (and it will keep changing) in case your team is looking for some workflow inspiration.
Style guide for issue tagging
Label Groups
We group labels by color, according to broad themes. Labels are consistent across repositories, except for a few language specific topics. This makes switching between projects easy, since you don't need domain expertise in order to write an issue.
New team members can learn the system once, and use it everywhere.
Platform
If the repository covers multiple parts, this is how we designate where the issue lives. (i.e. iOS and Android for cross-platform tablet app).
Problems
Issues that make the product feel broken. High priority, especially if its present in production.
Mindless
Converting measurements, reorganizing folder structure, and other necessary (but less impactful) tasks.
Experience
Affect user’s comprehension, or overall enjoyment of the product. These can be both opportunities and “UX bugs”.
Environment
Server environment. With good QA, you’ll identify issues on test and staging deployments.
Feedback
Requires further conversation to figure out the action steps. Most feature ideas start here.
Improvements
Iterations on existing features or infrastructure. Generally these update speed, or improve the quality of results. Adding a new “Owner” field to an existing “Calendar” model in the API, for example.
Additions
Brand new functionality. New pages, workflows, endpoints, etc.
Pending
Taking action, but need a few things to happen first. A feature that needs dependencies merged, or a bug that needs further data.
Inactive
No action needed or possible. The issue is either fixed, addressed better by other issues, or just out of product scope.
See a version of this in action on one of our public repos. Want to see what we're building? Check out our product features.
Quickstart for GitHub Issues
Follow this brief interactive guide to learn about GitHub Issues.
В этом руководстве показано, как использовать GitHub Issues для планирования и отслеживания элемента работы. В этом руководстве вы создадите новую проблему и добавите к ней список задач для отслеживания вложенных задач. Вы также узнаете, как добавлять метки, вехи, уполномоченных и проекты для обмена метаданными о проблеме.
Чтобы создать проблему, вам потребуется репозиторий. Вы можете использовать существующий репозиторий, к которому у вас есть доступ для записи, или создать репозиторий. Для репозитория должны быть включены проблемы. Дополнительные сведения о создании репозитория см. в разделе Creating a new repository. Дополнительные сведения о включении проблем, если они отключены в репозитории, см. в разделе Отключение проблем.
Открытие пустой проблемы
Сначала создайте проблему. Существует несколько способов создавать проблемы, и вы можете выбрать наиболее подходящий для вашего рабочего процесса. В этом примере будет использоваться пользовательский интерфейс GitHub. Дополнительные сведения о других способах создания проблемы см. в разделе Creating an issue.
-
На GitHub.com перейдите на главную страницу репозитория. 2. Под именем репозитория щелкните
Проблемы.
1. Щелкните Новая проблема.
Присвойте вашей проблеме описательное название. Это название должно с первого взгляда дать общее понимание контекста.
Добавьте описание, которое объясняет назначение проблемы, и добавьте в него все сведения, которые могут помочь в устранении проблемы. Например, если вы оформляете отчет об ошибке, опишите шаги для воспроизведения ошибки, ожидаемый и фактический результаты.
Вы можете использовать разметку Markdown для форматирования, ссылок, смайликов и так далее. Дополнительные сведения см. в разделе Создание документов на GitHub.
Добавление списка задач
Иногда удобно разбивать большие проблемы на мелкие задачи или отслеживать несколько однотипных проблем в одной более крупной проблеме. Добавьте в проблему список задач, снабжая каждый элемент списка префиксом [ ] . Укажите ссылки по номерам или URL-адресам на другие существующие проблемы. Вы можете создать в формате обычного текста задачи, которые не сопоставляются с определенной проблемой, а позднее преобразовать их в проблемы. Дополнительные сведения см. в разделе About task lists.
Добавьте метку для классификации проблемы. Например, можно использовать метку bug и метку good first issue , чтобы обозначить проблема как ошибку, за исправление которой может взяться новый участник. Пользователи могут фильтровать проблемы по меткам, чтобы получить все проблемы с определенной меткой.
Вы можете использовать стандартные метки или создать собственные. Дополнительные сведения см. в разделе Managing labels.
Вы можете добавить веху для отслеживания проблемы в рамках целевого объекта на основе дат. Веха отображает ход решения проблем по мере достижения целевой даты. Дополнительные сведения см. в разделе About milestones.
Чтобы обозначить зоны ответственности, вы можете назначить проблему определенному участнику в организации. Дополнительные сведения см. в разделе Assigning issues and pull requests to other GitHub users.
Добавление проблемы в проект
Вы можете добавить проблему в существующий проект и заполнить метаданные для проекта. Дополнительные сведения о проектах см. в разделе «About Projects».
Щелкните Отправить новую проблему, чтобы создать проблему. После создания проблемы можно изменить любое из описанных выше полей. У вашей проблемы есть уникальный URL-адрес, который можно передать другим участникам команды, указать в описании других проблем или запросов на вытягивание.
После создания проблемы продолжайте общение, добавляя комментарии к проблеме. Вы можете указать коллег или команды в @mention, чтобы привлечь их внимание к комментариям. Чтобы связать связанные проблемы в том же репозитории, можно ввести # перед заголовком проблемы, а затем щелкнуть проблему, которую нужно связать. Дополнительные сведения см. в разделе Создание документов на GitHub.
Проблемы можно использовать для широкого спектра задач. Пример:
- Отслеживание идей
- Сбор отзывов
- Задачи по планированию
- Информирование об ошибках
Далее приведены некоторые полезные ресурсы для выполнения следующих этапов с помощью GitHub Issues.
Как эффективно работать с тикетами (issues) на GitHub
Тикеты на GitHub бывают разные: запросы на реализацию каких-то возможностей, отчёты об ошибках, жалобы от клиентов, оповещения от систем безопасности, ретроспективы для команды и т. д. Здесь мы рассмотрим, как команда может использовать и обсуждать их.
Содержание:
Что такое тикет?
Для многих команд «тикет» — это общий термин, который может означать:
- Запрос на реализацию фичи.
- Отчёт об ошибке.
- Жалобу клиента.
- Оповещение системы безопасности.
- Ретроспективу для команды.
Публичный или приватный?
Для проектов можно создавать публичные и приватные тикеты. Публичные, как правило, предназначены для пользователей, клиентов, агентов и т. д. Приватные — для разработчиков, подрядчиков, партнёров и т. д.
Для публичных тикетов
- Акцентируйте внимание на итоге.
- Подчёркивайте, что можно сделать.
- Не публикуйте конфиденциальную информацию.
Для приватных тикетов
- Акцентируйте внимание на подробностях.
- Выделяйте исследовательскую информацию, потому что это помогает выявлять возможные закономерности между разными тикетами.
- По мере необходимости добавляйте конфиденциальную информацию.
Оценка
Все тикеты надо оценивать таким образом, чтобы иметь возможность сравнить их друг с другом и понять, над чем именно нужно работать. Есть разные способы оценки, и на практике хорошо работают следующие.
Оценка по приоритетности
- Пример: Приоритетность 1 (сделать в первую очередь), Приоритетность 2 (сделать во вторую очередь), Приоритетность 3 (сделать в третью очередь) и т. д.
- Аналогия: список дел, в котором Приоритетность 1 является главным приоритетом.
- Достоинства: легко понять, в какой очерёдности команда будет выполнять задачи. Совместимо со многими системами отслеживания ошибок, приложениями для ведения списков дела и инструментами для управления задачами.
- Не рекомендуется: некоторые команды используют Приоритетность 0 (P0), например, для обозначения экстренных ситуаций или помехи релиза.
Оценка по степени влияния
- Пример: от Опасность 1 (минимальное влияние) до 5 (катастрофическое влияние).
- Аналогия: возможные последствия ураганов оцениваются по шкале Саффира-Симпсона в диапазоне 1 (минимальный), 2 (умеренный), 3 (значительный), 4 (огромный), 5 (катастрофический).
- Достоинства: легко понять с точки зрения влияния на бизнес. Хорошо подходит для цветового кодирования от зелёного до красного. Каждый может выставить оценку в соответствии со своей точкой зрения, без учёта приоритетности.
- Не рекомендуется: некоторые команды переворачивают шкалу и используют диапазон от Опасность 0 (катастрофическое) до 5 (минимальное). Мы не рекомендуем так делать, потому что возникает диссонанс.
Оценка по степени ущерба
- Пример: от Ущерба 1 (минимальный ущерб) до 10 (катастрофический ущерб).
- Аналогия: шкала Рихтера оценивает ущерб от землетрясений в диапазоне от 1 (минимальные разрушения) до 10 (полные и необратимые разрушения).
- Достоинства: легко понять с точки зрения влияния на клиентов. Можно использовать аналогии из реального мира. Хорошо подходит для кодирования по степени яркости в диапазоне от светлого до тёмного. Каждый может выставить оценку в соответствии со своей точкой зрения, без учёта приоритетности.
Оценка по размеру
- Пример: по увеличению размера — «Маленькое», «Среднее», «Большое».
- Аналогия: размеры одежды.
- Достоинства: легко прикинуть, сколько потребуется сделать работы.
Оценка по критерию MoSCoW
- Пример: MoSCoW — это мнемоническое сокращение от «must», «should», «could», «won’t». Фича «должна быть», «желательна», «может быть», «не будет».
- Аналогия: любая беседа, посвящённая планированию, в ходе которой кто-то говорит: «Мы должны это сделать» или «Нам следует это сделать».
- Достоинства: англоязычное кодирование категорий помогает говорить о тикетах с заинтересованными лицами. Система широко используется специалистами по пользовательскому взаимодействию.
Оценка по частоте
- Пример: «Частота 1 %» означает, что затронут 1 % случаев, «Частота 100 %» — затронуты все случаи.
- Аналогия: частота возникновения чего-либо или повторения в течение заданного периода или в рассматриваемом образце.
- Достоинства: позволяет оценить, насколько часто возникает проблема. Можно преобразовывать в оценки вроде «20 раз в день». Можно подытоживать в виде «всегда», «часто», «иногда», «редко», «никогда». Можно выражать в процентах: «Затронуто 80 % случаев».
Совокупная оценка
Пример: оценивание тикета по комбинации приоритетности, влияния, ущерба, размера, MoSCoW и частоты.
Допустим, в офис приехал важный клиент, чтобы в течение часа подписать договор, а команда продавцов обнаружила на сайте опечатку в названии компании клиента.
- Продавцы сначала задают тикету Приоритетность 1.
- Продуктологи задают Опасность 1 (минимальное влияние), потому что опечатка тривиальна и не влияет на других клиентов.
- Маркетологи задают Ущерб 3 (средний), потому что опечатка сказалась на предоплате.
- Менеджер проекта задал «маленький» размер, потому что объём работ невелик.
- Проектировщики задали MoSCoW «должна быть», потому что это необходимо исправить.
- Команда по качеству задала Частоту 2 %, потому что проверка выявила опечатки в 2 % наименований клиентов.
Обсуждение оценок
Здесь приведены примеры обсуждения оценок тикетов.
— Обычно кроме опасности независимо оценивается и частота. Если баг вряд ли проявится при обычном использовании, то даже при высокой опасности приоритетность может быть понижена. Обычно так управляют рисками.
— Разработчик или тестировщик может хорошо оценивать опасность бага, но он не знает, столкнутся с этой проблемой все пользователи или только некоторые из них. Частота — это другое измерение. Приоритетность можно вычислить, умножив опасность на частоту.
— Форма должна быть такой: опасность * частота — лёгкость обходного решения = приоритет. Если какой-то из членов уравнения меняется (например, найдено новое обходное решение, или выясняется, что на падающую веб-страницу почти никто не заходит), тогда приоритет скорректируется. Одна лишь опасность без «оценки количества людей, на которых это повлияет» и «насколько сильно это на них повлияет?» выглядит лишь частью общей картины.
— QA-инженер в ходе начального исследования задал опасность на основе технических критериев. Это лишь один из факторов, которые продуктолог использует при определении приоритетности, которая с этого момента становится ключевым параметром.
— У некоторых пользователей программа иногда вылетает, они теряет всю сделанную работу и очень сильно злятся. Они присваивают тикету высочайшую опасность. Но если с проблемой сталкивается только один человек, и это происходит периодически, причём пользователь уже приспособился чаще сохраняться, тогда продуктологу следует задать тикету более низкую приоритетность.
— Опасность характеризует восприятие проблемы человеком: если он сталкивается с ней в определённом случае, то он оценит опасность как максимальную. Приоритетность описывает, как воспринимает баг команда управления проектом: более высокое значение получают баги, о которых сообщают наиболее ценные жалобщики — приносящие много денег клиенты, столкнувшийся с затруднениями директор и т. д. Не используйте опасность багов для оценки приоритетности, потому что они взаимосвязаны опосредовано.
— Опыт использования приоритетности и опасности подсказывает, что в теории различие между ними может быть, но в реальности большинство его не видят. Эти термины так часто путают, что они стали неразделимы.
— Внутренняя система отслеживания ошибок в Google оперирует и приоритетностью, и опасностью. P0 S0 — самая срочная задача, P2 S2 — стандартная, P4 S4 — наименее срочная. Это нечто вроде дежурной шутки, что опасность не имеет смысла (потому что по сути она не отличается от приоритетности).
— Мы используем только приоритетность. Тестировщик присваивает на основании эвристик начальное значение (например, падениям — П1, косметическим улучшениям — П5). Разработчик ориентируется на это значение, чтобы выбрать баги, с которыми нужно начать работать в первую очередь. А затем приоритетность корректируется в зависимости от пользовательского опыта и поведения приложения. Если нам действительно нужно посмотреть, какие значения задал тестировщик, то мы используем функцию «истории» или «ревизии» в нашем приложении для отслеживания ошибок.
Шаблон тикета
Шаблон поможет вашей команде эффективно и ёмко охватить важные темы.
В нем могут использоваться:
- Главный жалобщик: общая характеристика проблемы, данная столкнувшимся с ней человеком.
- Участники: кто вовлечён в ситуацию — пользователи, сотрудники, партнёры, конкретные люди и т. д.
- Симптомы: очевидные признаки проблемы — мнения пользователей, триггеры, оповещения и т. д.
- История: вторичная информация, имеющая отношение к ситуации — аналогичные случаи, отчёты, ссылки и т. д.
- Диагноз: что происходит под капотом — исходные причины или цепочки причин, и т. д.
- Прогноз: оценка потенциальных последствий, изменений и т. д.
- Переломы: потерянная информация, падающее приложение, заблокированный процесс и т. д.
- Лечение: что мы делаем для улучшения ситуации — процедуры, списки дел, ограничения и т. д.
Запуск постмортемов
Запуск постмортемов подскажет команде, когда нужно заняться описанием ситуации.
Github какие теги использовать для issue
An Issue in GitHub is a sort of bug tracker for a project which has its own section in every repository. It can be used for discussions which include a variety of things like reporting a bug on that repository, asking questions or even asking for a particular feature. It is a great place to keep a track of tasks and enhancements of the project. Being good at writing issues often helps in building better open source projects and will help other contributors to understand your project better and help you.
To make a new issue in your repository, navigate to the repository where you want to raise an issue and go to the Issues tab as shown below:
After navigating to the issues tab, click on New Issues to create an Issue for your project as shown below:
Then give a suitable heading and detailed information about the issue. As an example, let us take a look at angular repository which is a web framework:
Features of Issues
An issue contains the following entities:
- A title and a description which clearly explains what the issue is about. It should be concise and should be clear to understand.
- Color-coded labels that help to filter out specific issues for you. This is similar to the categorization we see in emails. An issue can have more than one label and can be filtered out by one or many labels at a time. An issue with labels looks like this:
- Milestones help to track issues and merge requests to achieve a broader goal in a certain duration of time. They can be visualized as containers for specific type of issues. These can be of various types for example:
- Version 1.0 – For a specific release of a software version.
- Beta Launch – File bugs that you need to fix before you’ll launch the beta version of your project.
- March Due – File issues that you’d like to work in March.
- Redesign – Issues related to the design of your project.
Some other useful features in issues are:
- @mention – A great way to reference other users within GitHub is using the @mention feature. To notify other users of a particular issue and to seek help or guidance from them, tag them by using @username which sends them a notification to look into the issue and contribute to it. It can also be used to notify teams rather than individuals, in which all the team members will be notified.
- References – Sometimes some issues are dependent on other issues. These issues can be referenced by placing a # in front of issue_number of the other issue which is dependent on the current issue and prefacing the commits with “Fixed”, “Fixes”, “Closed”, “Closes” or “Close”.
- Searches – At the top-right in the issues section, there is a search box which lets you search through the issues present. Issues can be searched on the basis of keywords, states or assignees.
Finally, there is an issue dashboard which lists all your issues from all the projects you’ve been working on and includes:
Функции GitHub : Issues, Projects, Pull Requests
Здравствуйте! Помогите, пожалуйста, разобраться с такими функциями GitHub как Issues, Projects, Pull Requests. Для чего они нужны и как правильно с ними работать. У меня есть репозиторий, в котором 2 текстовых файла. И к этому репозиторию надо применить эти функции. Заранее, огромное спасибо!
Issues — это система учёта ошибок, по-английски bugtracker.
Конечно, она не такая навороченная, как, к примеру Jira. Однако разработчики Github-а считают эту простоту преимуществом благодаря гибкости и отсутствию визуального мусора.
Так как у Github Issues отсутствуют такие важные поля, как «Категория», «Серъёзность», «Статус» и «Компонент», их приходится заменять проставлением различных меток. Вот как это предлагает делать некто Zach Dunn:
Интересной особенность GitHub является то, что нумерация сообщений в Issue Tracker-e является общей с Pull Requests, хотя эти два понятия не пересекаются и находятся в разных категориях.
Более подробно о Github Issues можно прочитать в официальной справке.
Projects — это хранилище заметок. Больше о нём и сказать нечего, кроме упоминания возможности упорядочивать заметки по столбцам (категориям) и строкам. Вот, собственно, и всё. Можете хоть хранить напоминания, хоть организовать доску для канбана.
Pull Requests — это заявка на принятие ваших изменений в центральный репозиторий. Является неотъемлемой частью Github Flow.
Предполагается, что вы вели разработку в своей, публично доступной копии репозитория — форке. Публичность нужна для возможности улучшения вашей копии другими пользователями перед окончательным включением ваших изменений в центральный репозиторий.
GitHub Issues: Tagging Best Practices — Save Time!
For people who make software, the internet has no shortage of best practice for workflow organization like Git Flow, release versioning, GitHub, etc. When you get to the topic of issue management, the reading material plummets.
At Robin, GitHub issues are the core of just about every action the team takes. Over the past year, we've worked out an internal tagging system that keeps engineering and product efforts organized across repositories on Github. We're sharing the current iteration (and it will keep changing) in case your team is looking for some workflow inspiration.
Style guide for issue tagging
Label Groups
We group labels by color, according to broad themes. Labels are consistent across repositories, except for a few language specific topics. This makes switching between projects easy, since you don't need domain expertise in order to write an issue.
New team members can learn the system once, and use it everywhere.
Platform
If the repository covers multiple parts, this is how we designate where the issue lives. (i.e. iOS and Android for cross-platform tablet app).
Problems
Issues that make the product feel broken. High priority, especially if its present in production.
Mindless
Converting measurements, reorganizing folder structure, and other necessary (but less impactful) tasks.
Experience
Affect user’s comprehension, or overall enjoyment of the product. These can be both opportunities and “UX bugs”.
Environment
Server environment. With good QA, you’ll identify issues on test and staging deployments.
Feedback
Requires further conversation to figure out the action steps. Most feature ideas start here.
Improvements
Iterations on existing features or infrastructure. Generally these update speed, or improve the quality of results. Adding a new “Owner” field to an existing “Calendar” model in the API, for example.
Additions
Brand new functionality. New pages, workflows, endpoints, etc.
Pending
Taking action, but need a few things to happen first. A feature that needs dependencies merged, or a bug that needs further data.
Inactive
No action needed or possible. The issue is either fixed, addressed better by other issues, or just out of product scope.
See a version of this in action on one of our public repos. Want to see what we're building? Check out our product features.
Введение в GitHub для разработчиков
GitHub — это веб-сайт, на котором размещены миллиарды строк кода. Ежедневно миллионы разработчиков собираются там для совместной работы и решения разного уровня задач в публичном режиме с открытым исходным кодом.
Короче говоря, это платформа для разработчиков программного обеспечения, основанная на GIT.
Как разработчик, вы не сможете избежать ежедневного использования GitHub или другого инструмента на основе GIT во время своей работы. Он используется либо для размещения кода, либо для совместной работы над кодом других людей. В этой статье объясняются некоторые ключевые концепции GitHub, как пользоваться его функциями для улучшения рабочего процесса.
Почему GitHub?
Теперь вы знаете, что такое GitHub и наверняка задаетесь вопросам – зачем мне его использовать и как?
В конце концов, GitHub управляется частной компанией, которая получает прибыль от размещения чужого кода. Так почему вы должны использовать этот сайт вместо аналогичных платформ, таких как BitBucket или GitLab?
Помимо личных предпочтений и технических причин, есть одна значимая причина: все используют GitHub, поэтому сетевой эффект огромен.
Со временем основные кодовые базы были перенесены из других систем контроля версий в GIT из-за его удобства. GitHub исторически находится в выгодном положении и прилагает много усилий для удовлетворения потребностей сообщества открытого исходного кода.
Сегодня, когда вы будете искать какую-либо библиотеку, вы в 99% случаев найдете ее на GitHub.
Помимо открытого исходного кода, многие разработчики также размещают частные репозитории на GitHub из-за удобства платформы.
Теперь давайте приступим к важным концепциям GIT, которые разработчик должен знать.
GitHub Issues
GitHub Issues – одна из наиболее популярных в мире систем отслеживания багов.
Она предоставляет владельцам репозиториев возможность организовывать, отмечать тегами и привязывать проблемы к контрольным точкам.
Если вы найдете проблему в проекте, управляемом кем-то другим, она будет открытой до тех пор, пока вы не закроете ее (например, если выясните, в чем заключается проблема) или пока владелец репозитория не закроет ее.
Иногда вы будете получать окончательный ответ, а иногда проблема будет оставаться открытой и будет помечена некоторой информацией, которая ее классифицирует. Затем разработчик может вернуться к тегу, чтобы исправить проблему или улучшить кодовую базу с помощью ваших отзывов.
Большинству разработчиков не платят за поддержку их кода, выложенного на GitHub, поэтому нельзя ожидать быстрых ответов. Но некоторые репы с открытым исходным кодом публикуются компаниями, которые предоставляют услуги для этого кода. Они предлагают коммерческие предложения для версий с большим количеством функций или используют архитектуру на основе плагинов. Поэтому они платят разработчикам, работающим над проектом с открытым исходным кодом.
Социальное кодирование
Несколько лет назад в логотип GitHub входил слоган «социального кодирования».
Что это значит? Важен ли сейчас этот слоган? Конечно.
Подписки (Follow)
На GitHub можно подписаться на разработчика или репозиторий, зайдя в профиль пользователя и нажав «Подписаться» или нажав кнопку «Следить» в репозитории.
В обоих случаях активность будет отображаться в вашей ленте. Подписка на пользователя или на его репозиторий не напоминает Twitter, где вы видите, что говорят люди. Вместо этого вы видите, что люди делают.
Звезды (Stars)
Важная особенность GitHub – возможность оценить репу звездой. Это действие включит его в ваш список «помеченных репозиториев», что позволит отслеживать проекты, которые вам интересны, и находить похожие проекты.
Это также один из самых важных рейтинговых механизмов: чем больше у репозитория звезд, тем он популярнее и важнее. Это приводит к тому, что он становится более заметен в результатах поиска.
Крупные проекты могут иметь десятки тысяч звезд.
GitHub также имеет страницу трендов . На ней представлены репозитории, которые получили наибольшее количество звезд за определенный период времени (например, сегодня, на этой неделе или в этом месяце).
Попадание в эти трендовые списки может вызвать другие сетевые эффекты, такие как показ на других сайтах. Это вызвано тем, что у вас больше видимости.
Ответвления (Fork)
Последний важный сетевой индикатор проекта — это количество ответвлений.
Это ключ к тому, как работает GitHub. Ответвление — это основа запроса на включение (PR), который является предложением об изменении. Человек может добавить ответвление к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения в исходник.
Иногда человек, который разветвляет хранилище, может никогда не попросить вас объединить что-либо. Он может добавить ответвление к вашему репозиторию только потому, что ему понравился ваш код, и он решил добавить к нему что-то, что не хочет сливать обратно в исходную репу. Пользователь может также исправить ошибку, с которой он столкнулся и которая была важна для него.
Чем популярнее, тем лучше
В общем, это все – ключевые показатели популярности проекта. Помимо вышеуказанных индикаторов, дата последней версии и участие автора в трекере багов – полезные признаки того, стоит ли полагаться на библиотеку или программное обеспечение.
Запросы на включение (Pull requests)
В предыдущем разделе я объяснил, что такое запрос на включение (PR). Повторим: человек может добавить расширение к вашему репозиторию, внести некоторые изменения, а затем создать запрос на включение, чтобы попросить вас объединить эти изменения.
Проект может иметь сотни PR. Как правило, чем популярнее проект, тем больше PR. Например, в проекте React:
Как только человек отправляет запрос на включение, он должен быть рассмотрен основными управляющими проекта.
В зависимости от объема вашего запроса включения (количества изменений, количества вещей, затронутых вашим изменением, или сложности затронутого кода) управляющему может потребоваться больше или меньше времени на то, чтобы убедиться, что ваши изменения совместимы с проектом.
Проект может иметь четкую временную шкалу изменений, которые нужно внести. Управляющий может захотеть все упростить, если вы будете вводить сложную архитектуру в запрос на включение.
Это означает, что запрос на включение не всегда принимается быстро. Нет никакой гарантии, что запрос когда-либо будет принят.
В примере, который я разместил выше, в репозитории есть запрос на включение, который был создан 1,5 года назад. Это происходит во всех проектах. Это вполне нормально и может быть связано с причинами, которые я упомянул выше.
Управление проектами (Project management)
Наряду с issues, благодаря которым разработчики получают обратную связь от пользователей, интерфейс GitHub предлагает и другие функции, позволяющие управлять проектами.
Одна из них – Projects. Это новый раздел, который очень редко используется. Это система «Канбан», которая помогает организовать баги и работу, которую необходимо выполнить.
Wiki предназначена для использования в качестве документации для пользователей. Одним из наиболее впечатляющих применений Wiki, которое я видел, является GitHub Wiki языка программирования Go .
Также в управлении проектами помогают контрольные точки. Это часть страницы issues. Вы можете соотнести проблемы с определенными контрольными точками, которые могут быть целями релизов.
Представив релизы, GitHub расширил функциональность тегов GIT.
Тег GIT — это указатель на конкретную версию. Если он выполняется последовательно, то помогает вам вернуться к предыдущей версии кода без ссылки на конкретные версии.
Релиз GitHub построен на основе тегов GIT и представляет собой полную версию вашего кода, а также zip-файлы, заметки о выпуске и двоичные ресурсы, которые могут представить полностью рабочую версию конечного продукта кода.
Хотя тег GIT можно создавать программно (например, с помощью тега git из командной строки), создание релизов GitHub – это ручной процесс, который происходит в пользовательском интерфейсе GitHub. Вы, по сути, говорите GitHub создать новый релиз и сообщаете, к какому тегу вы хотите применить его.
Сравнение коммитов
GitHub предлагает множество инструментов для работы с кодом.
Одна из самых важных вещей, которые вы можете сделать, — это сравнить одну ветку с другой. Вы также можете сравнить последний коммит с тем, который используете в данный момент, чтобы увидеть, какие изменения были внесены с течением времени.
GitHub позволяет вам делать это с compare view: просто добавьте /compare в конец имени репозитория.
На рисунке ниже я сравниваю последнюю версию React v15.x с последней версией v16.0.0-rc, доступной на момент написания этой статьи, чтобы увидеть, что изменилось.
В этом представлении отображаются коммиты, сделанные между двумя релизами (или тегами, или ссылками на коммиты), которые были изменены, и фактические различия, если число изменений меньше разумного значения.
Webhooks и Services
GitHub предоставляет множество функций, которые помогают рабочему процессу разработчика: например, вебхуки и сервисы.
Webhooks
Вебхуки позволяют пинговать внешние сервисы, когда в репе происходят определенные события. Например, это может произойти, когда для кода используется команда push, создается ответвление или если тег создается или удаляется.
Когда происходит событие, GitHub отправляет запрос POST на URL, который мы говорим ему использовать.
Обычно эта функция используется для проверки связи с удаленным сервером. Это нужно, чтобы получить последний код из GitHub, когда мы отправляем обновление с нашего локального компьютера.
Мы отправляем команду push к GitHub, GitHub сообщает серверу об этом, и сервер извлекает данные из GitHub.
Services
Сервисы GitHub и новые приложения GitHub представляют собой сторонние интеграции, которые улучшают работу разработчика или предоставляют услуги.
Например, вы можете установить исполнитель тестов для автоматического запуска тестов каждый раз, когда вы делаете новые коммиты. Здесь поможет TravisCI .
Можно настроить непрерывную интеграцию с помощью CircleCI .
Можно создать интеграцию Codeclimate , которая анализирует код и предоставляет отчет «Техническая задолженность» и покрытие тестирования.
Заключение
GitHub — это замечательный инструмент и сервис, которым можно воспользоваться. Это настоящий драгоценный камень в современном наборе инструментов для разработчиков. Данное руководство поможет вам начать работу. Реальный опыт управления проектами с открытым или закрытым исходным кодом GitHub (как пользоваться им, показано во многих статьях) — это то, что нельзя упустить.