Code Review
OneDev combines branch protection, pull-request reviews, inline discussions, and CI reports. This walkthrough uses a disposable project and two reviewers. The source-annotation example provides a small JavaScript change with test coverage and deliberate lint findings to review.
Configure review requirements
In the project's Settings / Branch Protection, add a rule for the target branch. Specify required reviewers and, where appropriate, required jobs. You can require reviews for particular file patterns and select reviewers from a group. For example, require a member of your core team when changes touch model files.
Prepare the build specification before making a job required. Add a Pull Request Update trigger so the job checks the test merge of the source and target branch heads. If the target branch is already protected, edit the build specification on a separate branch and submit that change through the normal review process. Keep protection enabled.
A trigger schedules a job; branch protection makes that job a merge requirement. A failed optional job alone does not necessarily block merging.
When a group supplies reviewers, OneDev uses the history of changed files to help choose members. Review the proposed reviewers when opening the pull request. Add other reviewers when their input is needed. A required review cannot be bypassed by simply removing its reviewer.
Inspect the changes
Open File Changes. The revision selector initially shows base ... head. Select one commit, or Shift-click to select multiple commits. After submitting a review, the selector also lets you inspect changes since that review.
Use Filter by path to focus on relevant files, such as src/*.test.js. Mark a file reviewed with the checkbox icon beside its name. The reviewed-file count tracks this browsing state; it is separate from approving the pull request.
Click a symbol to inspect its definitions or occurrences when supported by the language. Coverage and problem markers appear when CI has published reports for the relevant revisions. Click a problem marker for its details; covered and uncovered line markers help identify missing tests. See the Jest/ESLint setup.
Discuss and suggest changes
Drag over a code range and choose Add comment on this selection. Explain the concern and save the comment. To propose replacement code, use the editor's suggestion action or a fenced suggestion block. An empty suggestion block proposes deleting the selected line.
The submitter can find discussions in Code Comments, then open the linked selection. With write access to the source branch, use Commit suggestion to apply a suggestion, or add compatible suggestions to a batch and commit them together. Review the resulting diff and commit message before confirming.
Applying a suggestion creates a source-branch commit and resolves its code comment. In this example, committing the deletion removes unusedAdd; the remaining lint finding must still be addressed. Ordinary comments can be resolved separately once the discussion is complete. New commits run the configured CI trigger and may require another review.
Submit a review
Choose Request For Changes when work remains, and explain what must change. The pull request stays blocked while a reviewer requests changes. In the example, remove both unused variables and add a divide-by-zero test; the follow-up CI build then passes.
Review the updated commits and choose Approve when satisfied. All listed reviewers must approve, and any other branch-protection requirements must also pass, before the pull request can merge. Use the pull request's current status and job results to see what remains.
Review outside a pull request
You can also select code in a file or commit view to start a code discussion. These comments remain associated with their source location and can help explain code history. Applying a suggestion outside a pull request requires choosing the branch to update and having permission to write to it.