Resolve conversation github что это
Перейти к содержимому

Resolve conversation github что это

  • автор:

Who should mark PR comments as resolved?

However, Bob misunderstood the bug fix, and didn’t fix it correctly. Jane, who spotted the bug hasn’t had chance to review/accept the new changes, as Bob wrongly completed the PR comment on her behalf. Unreviewed code has now made it into the main branch, which could well be CI/CDing straight to production!

If the author of the PR comment is always the person who has the responsibility of marking that comment as resolved — this gets rid of this problem, and all changes will have had by at least two people’s eyes on them.

How to resolve a GitHub Pull Request conversation (comment thread) using GitHub API?

I’m working on a process to migrate a repo from GitLab to GitHub.
One of the things this process needs to do is recreate Merge Requests from GitLab as Pull Requests in GitHub, along with their conversation history. I managed to use the GitHub API to create the PR and comments from the original MR, but as some comment threads in the original MR were already resolved I wanted to use the API to mark those conversations in the PR as resolved as well, but I couldn’t find a way to do it. Right now I just add a final comment to the conversation that says it it resolved, but I’m wondering if there is a better way to do it.

asked Mar 10, 2022 at 8:37
Zohar Meir Zohar Meir
585 1 1 gold badge 4 4 silver badges 16 16 bronze badges

2 Answers 2

It’s only available in GraphQL at this point:

The GraphQL seems straightforward but it’s not. The input of that mutation requires an id of something called «review thread» but there’s no such concept in the REST API. With an id of «comment» from REST API, the only way to find the corresponding «review thread» is to retrieve all the review threads and filter by the comments inside.

Практическое занятие «Процесс Pull request на GitHub»

На предыдущем занятии Используем клиент GitHub для десктопа, мы использовали Github Desktop для управления рабочим процессом коммитов, ветвления и слияния. На этом занятии мы будем выполнять аналогичные действия, но с использованием браузерного интерфейса, который предоставляет Github, вместо использования терминала или Github Desktop.

Понимание процесса Pull request является важным для анализа изменений в опен-сорс проекте с несколькими участниками. Использование интерфейса GitHub также удобно, если рецензенты не знакомы с терминалом или Github Desktop.

Создание изменение в отдельной ветке

По умолчанию в новом репозитории есть одна ветка с именем «Master». Обычно, когда при внесении изменений или просмотра / редактировании, создается новая ветка и вносятся все изменения в ветку. Затем, по окончании, владелец репо объединяет изменения из новой ветки в «Master» через «pull request».

Note: Можно выполнять эти операции, используя команды Git в терминале, а также Можно выполнять их в интерфейсе браузера. Интерфейс браузера может быть полезен, если людей, вносящих изменения в ваш контент.

Для создания изменений в отдельной ветке:

new branch

  • Со стороны рецензента переходим к тому же репозиторию GitHub, который был создан на предыдущем занятии (можно создать новый репо). Создаем новую ветку, выбрав раскрывающееся меню ветки и введя имя новой ветки, например «sme-review». Затем нажмите клавишу Enter.

При создании новой ветки, содержимое из главной (или любой другой ветки, которая сейчас просматривается) копируется в новую ветку. Процесс похож на «Сохранить как» с существующим документом.

make edits

  • Кликаем в область ввода текста, а затем кликаем по иконке карандаша («Edit this file»), чтобы отредактировать файл.
  • Вносим изменения в контент и прокручиваем вниз экрана до области Commit changes. Поясняем причину изменений и подтверждаем изменения в своей ветке sme-review, нажав кнопку Commit changes .

Рецензенты могут продолжать вносить изменения таким образом, пока не закончат просмотр всей документации. Все изменения делаются в этой новой ветке, а не в мастере.

Создание Pull request

Теперь представим, что процесс проверки завершен, и пришло время объединить ветку с мастером. Ветка объединяется с “Master” через Pull request . Любой «соавтор» в команде с правами на запись может инициировать и завершить Pull request (добавлять соавторов можете в «Настройки»> «Соавторы)

Для создания Pull request:

  • Находим на экране вкладку “Pull request”.
  • Кликаем по кнопке New pull request

New pull request

  • Выбираем ветку (sme-review), которую хотим сравнить с веткой “Master”

compare

Когда мы сравниваем ветку с мастером, мы увидим список всех изменений. Мы можем просмотреть изменения в двух режимах просмотра: Unified или Split (это вкладки, показанные справа от содержимого). Unified показывает правки вместе в одной области содержимого, тогда как split показывает два файла рядом.

  • Кликаем на кнопку Create pull request .
  • Поясняем pull request и снова кликаем кнопку Create pull request .

Владелец репозитория увидит pull request и сможет принять меры для его объединения.

Процесс Pull request

Теперь посмотрим на процесс со стороны владельцем проекта, который получил новый Pull request. Владельцу нужно обработать Pull request и объединить ветку sme-review с “Master”.

Files changed

  • Переходим на вкладку “Pull requests”, чтобы увидеть ожидающие запросы на извлечение.
  • Кликаем по запросу и смотрим изменения, выбрав вкладку Files changed.

Note: Для реализации выборочных изменений, переходим в ветку sme-review и вносим обновления перед обработкой pull request. Pull request не дает построчную информацию о том, какие изменения мы хотим принять или отклонить (например, в Microsoft Word «Отслеживать изменения»). Слияние запросов — это процесс «все или ничего». Можно нажать кнопку Review changes , добавить несколько комментариев, а затем установить переключатель «Request changes», попросив рецензента внести изменения.

Также стоит обратить внимание, что если запрос на извлечение выполняется для более старой версии мастера, где исходное содержимое мастера больше не существует или перемещено в другое место, процесс слияния будет более трудным для выполнения.

  • Переходим на вкладку “Conversation” и кликаем кнопку Merge pull request .
  • кликаем Confirm merge .

Ветка sme-review объединяется с мастером. Теперь “Master” и ветка sme-review совпадают (ветки “смержены”).

  • Кликаем кнопку Delete branch для удаления ветки sme-review.

Не обязательно удалять ветку сразу. Старые ветки всегда можете удалить , щелкнув ссылку на ветки при просмотре репозитория Github, а затем нажмите кнопку Delete (корзина) рядом с веткой.

Если посмотреть на список веток, то после удаления ветка sme-review больше не отображается.

Добавление участников в проект

Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)

Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.

Для добавления соавторов в проект:

  • В репозитории проекта переходи на вкладку “Settings”.
  • Нажимаем на кнопку Collaborators в левой части.
  • Вводим имена пользователей Github тех, кому хотим дать доступ в области Collaborator.
  • Нажимаем на кнопку Add collaborator .

Комментирование в запросе на вытягивание

После открытия запроса на вытягивание в репозитории участники совместной работы или участники группы могут комментировать сравнение файлов между двумя указанными ветвями или добавлять комментарии общего характера к проекту в целом.

About pull request comments

You can comment on a pull request’s Conversation tab to leave general comments, questions, or props. You can also suggest changes that the author of the pull request can apply directly from your comment.

You can also comment on specific sections of a file in a pull request’s Files changed tab in the form of individual line comments, or as part of a pull request review. Adding line comments is a great way to discuss questions about implementation or provide feedback to the author. For more information about pull request reviews, see «About pull request reviews.»

For more information on adding line comments to a pull request review, see «Reviewing proposed changes in a pull request.»

Note: If you reply to a pull request via email, your comment will be added on the Conversation tab and will not be part of a pull request review.

To reply to an existing line comment, you’ll need to navigate to the comment on either the Conversation tab or Files changed tab and add an additional comment below it.

Tips:

  • Pull request comments support the same formatting as regular comments on GitHub Enterprise Server, such as @mentions, emoji, and references.
  • You can add reactions to comments in pull requests in the Files changed tab.

Adding comments to a pull request

  1. Under your repository name, click

Screenshot of the main page of a repository. In the horizontal navigation bar, a tab, labeled

Pull requests.

Screenshot of the tabs for a pull request. The

Files changed.

Screenshot of a diff in a pull request. Next to a line number, a blue plus icon is highlighted with an orange outline.

Hover over the line of code where you’d like to add a comment, and click the blue comment icon. To add a comment on multiple lines, click and drag to select the range of lines, then click the blue comment icon.

Screenshot of a review comment box. The file diff icon to suggest a specific change is outlined in dark orange.

, then edit the text within the suggestion block.

Anyone watching the pull request or repository will receive a notification of your comment.

Resolving conversations

You can resolve a conversation in a pull request if you opened the pull request or if you have write access to the repository where the pull request was opened.

To indicate that a conversation on the Files changed tab is complete, click Resolve conversation.

The entire conversation will be collapsed and marked as resolved, making it easier to find conversations that still need to be addressed.

If the suggestion in a comment is out of your pull request’s scope, you can open a new issue that tracks the feedback and links back to the original comment. For more information, see «Creating an issue.»

Discovering and navigating conversations

You can discover and navigate to all the conversations in your pull request using the Conversations menu that’s shown at the top of the Files Changed tab.

From this view, you can see which conversations are unresolved, resolved, and outdated. This makes it easy to discover and resolve conversations.

Screenshot of the

Further reading

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *