My team is currently conducting reviews with pull requests in GitHub. Why would we need Collaborator for reviews?
For some teams, pull requests in GitHub are enough to review code, especially for minor changes. While it might be convenient, simple GitHub reviews do dramatically limit your team's code review process. Through its GitHub integration, Collaborator enables teams to customize their review process to fit their unique needs and preferences. It is easy to create custom review templates to ensure that specific review priorities are being addressed and critical participants or groups are being included automatically.Your team is also able to mark defects and capture metrics on your review process, like defect type and severity, inspection rate, and lines of code reviewed. Your team can also go beyond just reviewing code since Collaborator supports reviews of many different types of document files, including Word, Excel, PowerPoint, Visio, PDF, and PNG files. If you need to review multiple artifact types and drive process improvement, integrating Collaborator with GitHub is easy and ensures that defects are found and fixed early on in your development.
When is a review created using the GitHub integration?
A review will be created when either a pull request OR push/commit is made to a branch that Collaborator is told to track.
How do I get to the review in Collaborator once one has been created by the GitHub integration?
When a review is created by a pull request OR push/commit, Collaborator will leave a comment with a link to the review on the pull request OR push/commit.
Can I create a review for a pull request from Collaborator?
No – the review is created when the pull request event occurs in GitHub with a destination branch monitored by Collaborator. To ensure reviews are created for all branches that need a review prior to merge, change your branch settings for that repositories integration.
Who’s account will the Collaborator review be associated with when it is created by the GitHub integration?
Collaborator will try to associate the GitHub user that initiated the pull request / commit with a Collaborator user. If the GitHub user name matches a Collaborator user name, the review will be created under that Collaborator account. If Collaborator cannot find any users that match the GitHub user name, it will check to see if any users have mapped their Collaborator user name to the GitHub user name; if it finds a match, the review will be created under that Collaborator account. If Collaborator cannot find any Collaborator users who match the GitHub user name, or are mapped to the GitHub user name, the review will be created under the Admin user.
As I continue to develop, can I update a review with new commits after a review is created?
If a review is created by a pull request, as you merge code into your pull request, the Collaborator review will be updated.
What happens if I perform rebasing operations on the commits involved in my pull request after a review is created?
The Collaborator review will update itself to match the git history of the pull request. For example, if you squash several commits in your pull request, the Collaborator review will reflect that. We won’t remove comments left on versions of a file that have been rebased out of a review.
What happens if I merge in upstream changes to my pull request after a review is created?
The Collaborator review will update accordingly, and by default, will not highlight these changes in the diff viewer.
What happens when I leave comments on a GitHub PR? How about a Collaborator review?
Comments will propagate from GitHub to Collaborator, but will NOT propagate from Collaborator to Github.