Pull Requests

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

Comment Threads

Each inline comment creates a thread (discussion):

• The PR author responds to feedback
• The reviewer marks the thread as Resolved
• Unresolved threads are visible in the PR summary

---

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 threads	All comment 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.