Skip to content
GitRiverGitRiver
RU
Navigation

Pull Requests

Creating, code review, merge strategies, merge queue, and CODEOWNERS in GitRiver

Pull Requests (PRs) are the primary way to propose code changes. An author creates a branch, makes changes, opens a PR - reviewers check the code, leave comments, and after approval the PR is merged into the target branch.

Creating a Pull Request

From the Command Line

# Create a branch and make changes
git checkout -b feature/new-api
# ... edit files ...
git add .
git commit -m "Add new API endpoint"
git push origin feature/new-api

After pushing, the UI will suggest creating a PR.

From the UI

  1. Click “New Pull Request” in the repository
  2. Select the source branch (with changes) and target branch (where to merge, usually main)
  3. Fill in:
    • Title - brief description of changes
    • Description - details, motivation, screenshots (Markdown)
    • Reviewers - who will review the code
    • Labels - categorization
    • Milestone - which release it belongs to
  4. Click “Create”

Pull Requests from Forks

External contributors can fork the repository and create PRs from their fork:

  1. Fork the repository (click “Fork”)
  2. Make changes in your fork
  3. Click “New Pull Request” - GitRiver will automatically detect the target repository

Draft

If a PR isn’t ready for review, create it as a draft. Drafts cannot be merged, but reviewers can leave comments. When ready, click “Ready for Review”.

Code Review

Viewing Changes

The Changes tab shows the diff of all files. Modes:

  • Unified - changes in a single column
  • Split - old and new code side by side

Inline Comments

  1. Hover over a line in the diff
  2. Click “+” to the left of the line
  3. Write a comment (Markdown)
  4. Click “Add Comment” (individual) or “Start Review” (batch)

Batch Review

Instead of sending comments one by one:

  1. Click “Start Review” on the first comment
  2. Leave all comments across different files
  3. Click “Finish Review” and choose the outcome:
    • Approve - code is ready to merge
    • Request Changes - needs work
    • Comment - no verdict, just notes

Discussion Threads

Added in 1.1.0.

A comment and the replies to it form a discussion thread. The thread is two levels deep: you reply to the comment, not to another reply.

  • Reply is left with the “Reply” button - both in the discussion and right in the diff. A reply hangs on the same line as the comment: it gets no anchor of its own, and the whole thread is marked outdated together when new commits arrive.
  • Marking resolved closes a settled comment: the thread collapses into one line and expands on click. The comment author, the pull request author and any participant with write access may set and clear the marker.
  • The unresolved counter is shown above the discussion and next to the change summary. If branch protection has the “require resolved discussion threads” rule enabled, the count is visible in the checklist next to the merge button.

CODEOWNERS

The CODEOWNERS file in the repository root automatically assigns reviewers based on file paths.

# .gitriver/CODEOWNERS

# Backend
/src/api/          @backend-team
/src/database/     @dba-team @backend-team

# Frontend
/src/web/          @frontend-team
*.tsx              @frontend-team

# DevOps
/deploy/           @devops
Dockerfile*        @devops
.gitriver/ci.yml   @devops

# Documentation
/docs/             @docs-team

Rules:

  • Last matching pattern takes priority
  • @username - specific user
  • @group/team - team within a group
  • If a PR modifies a file with a CODEOWNER, the reviewer is assigned automatically
  • Branch protection can require CODEOWNER approval

Merge Strategies

When clicking “Merge”, three strategies are available:

Merge Commit

* Merge pull request #42 (merge commit)
|\
| * Add new API endpoint
| * Fix validation
|/
* Previous commit
  • Creates a merge commit
  • Fully preserves branch history
  • Easy to revert the entire PR

Squash and Merge

* Add new API endpoint (#42)
* Previous commit
  • Combines all PR commits into one
  • Clean linear history
  • Intermediate commits (“fix typo”, “wip”) don’t clutter history

Rebase and Merge

* Fix validation
* Add new API endpoint
* Previous commit
  • Rebases commits onto the target branch
  • Linear history, each commit preserved
  • No merge commit

Configuration

In Repository Settings -> Merge you can:

  • Allow/disallow each strategy
  • Choose the default strategy
  • Enable auto-delete branch after merge

Merge Queue

Automatic merging with CI guarantee.

How It Works

  1. PR is approved and ready to merge
  2. Author clicks “Add to Queue” instead of “Merge”
  3. GitRiver creates a temporary branch with PR changes on top of current main
  4. CI runs on the temporary branch
  5. If CI passes - PR is merged automatically
  6. If CI fails - PR is removed from queue with notification

Why Use It

Without a queue, this scenario is possible:

  • PR A passed CI and awaits merge
  • PR B passed CI and awaits merge
  • PR A merges - main has changed
  • PR B was NOT tested on the new main - may break the build

The queue tests each PR against the current main before merging.

Configuration

Repository Settings -> Merge -> Merge Queue:

  • Enable/disable
  • Minimum batch size (how many PRs to combine for testing)
  • Maximum wait time

Merge Conditions

Configured through Branch Protection (details in the “Branch Protection” section):

Condition Description
Required CI checks All specified CI jobs must pass
Minimum approvals Number of approvals from reviewers (1, 2, …)
CODEOWNER approval At least one CODEOWNER approved
No conflicts Branch doesn’t conflict with target
Branch up to date Branch contains latest target commit
Signed commits All commits must be GPG/SSH signed
Resolved discussion threads All discussion threads must be resolved
Linear history No merge commits in the branch

Notifications

PR participants receive notifications for:

  • New comment or review
  • Status change (approved, changes requested, merged)
  • @ mention
  • Reviewer assignment
  • CI result (passed / failed)

Notification channels are configured in user profile settings.