resolve conversation github что это
Ревью кода системы средствами git
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
Проблематика
Представьте ситуацию: вам передают репозиторий с кодом и просят вынести свое мнение о нем. Обычно в подобных случаях замечания составляются в отдельном документе/таске/страничке в конфлюенс и т.п., что не очень удобно так как:
Метод ревью кода системы
Итак, нам нужно проделать следующее: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
На примере подготовленного для заметки репозитория https://github.com/oktend/system-review-example проделаем эти шаги:
Теперь наши ветки выглядят примерно так: 
https://github.com/oktend/system-review-example/network
Результат
В созданном merge request можно увидеть все собранные в ходе ревью замечания, даже обсудить их.
Состояние, для которого были выдвинуты замечания будет зафиксировано пока ветку явно не удалят.
Замечания можно просматривать в веб-интерфейсе github (или аналогов), в IDE, или средствами самого git.
К ревью можно будет вернуться в будущем сохранив замечания и контекст, в котором они были выдвинуты.
Примечания
Вполне допускаю возможность, что переизобрел велосипед и что для подобных случаев есть лучший метод, тогда буду благодарен за указание на лучший путь.
Идею для этого метода придумал не я, а предложил один разработчик, если Артем изъявит желание, укажу как автора.
About pull request reviews
In this article
Reviews allow collaborators to comment on the changes proposed in pull requests, approve the changes, or request further changes before the pull request is merged. Repository administrators can require that all pull requests are approved before being merged.
About pull request reviews
After a pull request is opened, anyone with read access can review and comment on the changes it proposes. You can also suggest specific changes to lines of code, which the author can apply directly from the pull request. For more information, see «Reviewing proposed changes in a pull request.»
Repository owners and collaborators can request a pull request review from a specific person. Organization members can also request a pull request review from a team with read access to the repository. For more information, see «Requesting a pull request review.» You can specify a subset of team members to be automatically assigned in the place of the whole team. For more information, see «Managing code review settings for your team.»
Reviews allow for discussion of proposed changes and help ensure that the changes meet the repository’s contributing guidelines and other quality standards. You can define which individuals or teams own certain types or areas of code in a CODEOWNERS file. When a pull request modifies code that has a defined owner, that individual or team will automatically be requested as a reviewer. For more information, see «About code owners.»
You can schedule reminders for pull requests that need to be reviewed. For more information, see «Managing scheduled reminders for pull requests.»
A review has three possible statuses:
Tips:
You can view all of the reviews a pull request has received in the Conversation timeline, and you can see reviews by repository owners and collaborators in the pull request’s merge box.
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 «Opening an issue from a comment.»
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.
Re-requesting a review
You can re-request a review, for example, after you’ve made substantial changes to your pull request. To request a fresh review from a reviewer, in the sidebar of the Conversation tab, click the
Repository administrators can require that all pull requests receive a specific number of approving reviews before someone merges the pull request into a protected branch. You can require approving reviews from people with write permissions in the repository or from a designated code owner. For more information, see «About protected branches.»
Tip: If necessary, people with admin or write access to a repository can dismiss a pull request review. For more information, see «Dismissing a pull request review.»
Write better code
On GitHub, lightweight code review tools are built into every pull request. Your team can create review processes that improve the quality of your code and fit neatly into your workflow.
See what’s possible
Start with a pull request
Pull requests are fundamental to how teams review and improve code on GitHub. Evolve projects, propose new features, and discuss implementation details before changing your source code.
Make a change
Start a new feature or propose a change to existing code with a pull request—a base for your team to coordinate details and refine your changes.
See every update
Diffs
Preview changes in context with your code to see what is being proposed. Side-by-side Diffs highlight added, edited, and deleted code right next to the original file, so you can easily spot changes.
History
Browse commits, comments, and references related to your pull request in a timeline-style interface. Your pull request will also highlight what’s changed since you last checked.
Pro-tip: You can search your commit history by keyword, committer, organization, and more.
Blame
See what a file looked like before a particular change. With blame view, you can see how any portion of your file has evolved over time without viewing the file’s full history.
Pro-tip: Use git blame to trace the changes in a file.
Discuss code
Comments
On GitHub, conversations happen alongside your code. Leave detailed comments on code syntax and ask questions about structure inline.
Review requests
If you’re on the other side of the code, requesting peer reviews is easy. Add users to your pull request, and they’ll receive a notification letting them know you need their feedback.
Reviews
Save your teammates a few notifications. Bundle your comments into one cohesive review, then specify whether comments are required changes or just suggestions.
Resolve simple conflicts
You can’t always avoid conflict. Merge pull requests faster by resolving simple merge conflicts on GitHub—no command line necessary.
Learn how to resolve merge conflicts on GitHub and using the command line.
Merge the highest quality code
Reviews can improve your code, but mistakes happen. Limit human error and ensure only high quality code gets merged with detailed permissions and status checks.
Permissions
Give collaborators as much access as they need through your repository settings. You can extend access to a few teams and select which ones can read or write to your files. The options you have for permissions depend on your plan.
Protected branches
Protected Branches help you maintain the integrity of your code. Limit who can push to a branch, and disable force pushes to specific branches. Then scale your policies with the Protected Branches API.
Required status checks
Create required status checks to add an extra layer of error prevention on branches. Use the Status API to enforce checks and disable the merge button until they pass. To err is human; to automate, divine!
Bulletproof your review process
Build on GitHub with review tools to avoid human error and add extra polish to your team’s code with review tools.
Codecov
Group, merge, archive and compare coverage reports
Codacy
Automated code reviews to help developers ship better software, faster
Coveralls
Ensure that new code is fully covered, and see coverage trends emerge
Commenting on a pull request
In this article
After you open a pull request in a repository, collaborators or team members can comment on the comparison of files between the two specified branches, or leave general comments on the project as a whole.
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 on 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 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 line comment below it.
Tips:
Adding line comments to a pull request
Under your repository name, click
Pull requests.
In the list of pull requests, click the pull request where you’d like to leave line comments.
On the pull request, click
Files changed. 
In the comment field, type your comment. 
Optionally, to suggest a specific change to the line or lines, click
, then edit the text within the suggestion block. 
When you’re done, click Add single comment. 
Anyone watching the pull request or repository will receive a notification of your comment.
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 «Opening an issue from a comment.»
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.
Support resolving conversations #339
Comments
Tyriar commented Aug 30, 2018
Needs support for deemphasizing outdated/resolved comments #89
The text was updated successfully, but these errors were encountered:
aoberoi commented Sep 11, 2018
I would like to add that I don’t necessarily want «outdated» comments hidden, but i would like «resolved» comments hidden. I hope that the resolve button is available and that these two properties can be filtered separately.
dylmye commented Sep 12, 2018
Looks like this property is currently exposed by the Github API: https://developer.github.com/v3/issues/comments/
adrian-ci commented Feb 19, 2019
This makes life really difficult because when using this to update my code from the code review it doesn’t distinguish between completed work (resolved comments) and in progress ones.
myartsev commented Apr 4, 2019
+1 just tried out the extension and can see myself using it regularly if resolving conversations directly from VSCode was possible, otherwise, there’s too much noise and I end up going directly to the GitHub website.
stgarf commented Jun 14, 2019 •
JaimieMurdock commented Jul 30, 2019
I would also really like to see this feature. I’m still reviewing PRs through the website instead of VSCode because of it. As @dylmye pointed out, it is exposed by the API. Would anyone have a pointer on what files need to be edited to add this support? I might be willing to work on this, but would need some mentorship.