# How Open‑Code‑Review Handles Pull Request Merging: A Technical Deep Dive

> Discover how Open-Code-Review handles pull request merging by computing merge bases and generating diffs for LLM review without altering repository state. Learn the technical details.

- Repository: [Alibaba/open-code-review](https://github.com/alibaba/open-code-review)
- Tags: deep-dive
- Published: 2026-08-04

---

**Open‑Code‑Review (OCR) never executes a `git merge`; instead, it computes the merge‑base between branches and generates a diff against the pull request head, feeding those changes to an LLM for review without altering repository state.**

The Alibaba open‑source tool Open‑Code‑Review automates code review using large language models, but unlike CI/CD pipelines, it deliberately avoids modifying repository state. Understanding how open‑code‑review handles pull request merging reveals a read‑only architecture designed for safety and precision, where the tool treats PRs as semantic ranges rather than merge operations.

## Why OCR Never Merges Your Pull Request

OCR is architected as a **read‑only analysis engine**. According to the source code in [`cmd/opencodereview/review_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/review_cmd.go), the tool never invokes `git merge` or writes to the repository. Instead, it resolves the reviewable range between two Git references, computes their common ancestor (the **merge‑base**), and examines the differences. This approach ensures that reviewing a pull request remains a completely safe operation that cannot corrupt branch history or introduce unintended commits.

## The 7‑Step Diff‑Based Review Workflow

When you invoke `ocr review --from main --to feature-branch`, the tool executes a precise sequence to extract the changes for AI analysis.

### 1. Parsing CLI References and Validating Inputs

The process begins in [`cmd/opencodereview/review_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/review_cmd.go), where the `reviewOptions` struct captures the `--from`, `--to`, and `--commit` flags. The function `validateReviewRefs` performs critical security checks to ensure supplied refs are valid commits and do not start with a hyphen (`-`), preventing ref‑option injection attacks.

```go
// From review_cmd.go – validating refs before any Git operation
opts := &reviewOptions{
    from:    *fromFlag,
    to:      *toFlag,
    commit:  *commitFlag,
}
if err := validateReviewRefs(opts); err != nil {
    return err
}

```

### 2. Determining the Review Mode

OCR supports three distinct review modes: **workspace**, **commit**, and **range**. The function `reviewModeFromOptions` (or `tool.ParseReviewMode` in later refactors) determines which mode applies based on which flags you provided. Range mode activates when both `--from` and `--to` are specified, which is the standard pattern for pull request reviews.

### 3. Computing the Merge‑Base for Range Reviews

For range reviews, OCR must identify the common ancestor to establish the baseline of changes. In [`cmd/opencodereview/delegate_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/delegate_cmd.go), the `mergeBase()` method executes `git merge-base` to find this point:

```go
func (dc *delegateContext) mergeBase(ctx context.Context) string {
    if dc.opts.from == "" || dc.opts.to == "" {
        return ""
    }
    out, err := dc.gitRunner.Run(ctx, "merge-base", dc.opts.from, dc.opts.to)
    if err != nil {
        return ""
    }
    return strings.TrimSpace(string(out))
}

```

If the mode is not range (e.g., reviewing a single commit), the function returns an empty string, indicating no merge‑base calculation is required.

### 4. Configuring the FileReader with Merge Context

With the merge‑base resolved, [`review_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/review_cmd.go) constructs a `tool.FileReader` that points to the target ref (the PR head) while retaining the merge‑base for comparison:

```go
mode := tool.ParseReviewMode(opts.from, opts.to, opts.commit)
ref, _ := mode.RefValue(opts.to, opts.commit)

fileReader := &tool.FileReader{
    RepoDir: cc.RepoDir,
    Mode:    mode,
    Ref:     ref,
    Runner:  cc.GitRunner,
}

```

This configuration allows the file reader to present the exact delta introduced by the pull request.

### 5. Generating the Diff with First‑Parent Semantics

The actual diff generation occurs in [`internal/diff/git.go`](https://github.com/alibaba/open-code-review/blob/main/internal/diff/git.go). When processing merge commits, OCR uses the `--diff-merges=first-parent` flag to render changes relative to the mainline parent. This produces the same view as `git show <merge‑commit>`, showing only the changes introduced on the feature branch side:

```go
out, err := p.runGit(
    ctx,
    "-c", "core.quotepath=false",
    "show", "--no-ext-diff", "--no-textconv",
    "--find-renames", "--src-prefix=a/", "--dst-prefix=b/",
    "--no-color", "--diff-merges=first-parent",
    "-U"+fmt.Sprint(DiffContextLines), "--end-of-options", p.commit,
)

```

### 6. Feeding Changes to the LLM Tool Registry

The computed diff flows into `cmd/opencodereview/buildToolRegistry`, which instantiates built‑in tools including `FileRead`, `FileFind`, `CodeSearch`, and `CodeCommentProvider`. These tools allow the LLM to query specific lines, search patterns, and propose comments based on the diff content.

### 7. Emitting Review Results Without Repository Changes

Finally, `agent.New` initializes the review agent with the tool registry, `ag.Run` executes the LLM analysis, and `emitRunResult` outputs the review comments. At no point does OCR write to the Git object database or modify working tree files.

## Critical Safety and Implementation Details

### Merge‑Base Calculation Logic

The merge‑base computation is strictly conditional. As implemented in [`delegate_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/delegate_cmd.go), the function returns early with an empty string unless both `--from` and `--to` are provided. This ensures that single‑commit reviews or workspace reviews skip unnecessary Git calculations.

### Handling Merge Commits in the Diff

When a pull request contains merge commits (from syncing with the base branch), the `--diff-merges=first-parent` flag ensures the review focuses only on the feature branch's unique changes. This aligns with standard GitHub/GitLab PR diff views, which show changes relative to the merge base rather than the full three‑way merge result.

### Ref‑Option Injection Protection

The `validateReviewRefs` function in [`review_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/review_cmd.go) explicitly rejects references beginning with `-`. This prevents attackers from crafting malicious branch names like `--force` that could be interpreted as command flags when passed to Git subprocesses.

## Practical Examples

Review a pull request by specifying the base and head branches:

```bash
ocr review --from main --to feature-branch

```

Review using a specific merge commit SHA (produces identical results for the changes introduced):

```bash
ocr review --commit abcdef1234567890

```

Programmatically configure the review range in Go:

```go
// Resolve review mode from CLI options
mode := tool.ParseReviewMode(opts.from, opts.to, opts.commit)
ref, _ := mode.RefValue(opts.to, opts.commit)

// Initialize file reader with computed merge-base context
fileReader := &tool.FileReader{
    RepoDir: cc.RepoDir,
    Mode:    mode,
    Ref:     ref,
    Runner:  cc.GitRunner,
}

```

## Summary

- **No actual merge execution**: OCR remains read‑only and never runs `git merge`, ensuring repository safety.
- **Merge‑base dependency**: The tool uses `git merge-base` in [`delegate_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/delegate_cmd.go) to establish the common ancestor for range reviews, determining exactly what changed in the PR.
- **First‑parent diff semantics**: Merge commits are rendered using `--diff-merges=first-parent` in [`internal/diff/git.go`](https://github.com/alibaba/open-code-review/blob/main/internal/diff/git.go), showing only feature branch changes.
- **Injection resistance**: `validateReviewRefs` in [`review_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/review_cmd.go) sanitizes inputs to prevent ref‑option attacks.
- **Range‑based architecture**: Pull requests are treated as diff ranges between two refs, not as merge operations.

## Frequently Asked Questions

### Does Open‑Code‑Review actually merge my pull request?

No. OCR is strictly a review tool and never modifies your repository. It computes the diff between the base and head commits using the merge‑base as a reference point, but it never creates merge commits or alters branch pointers.

### How does OCR determine which changes belong to a pull request?

OCR calculates the **merge‑base** (the common ancestor commit) of the source and target branches using the `mergeBase()` function in [`cmd/opencodereview/delegate_cmd.go`](https://github.com/alibaba/open-code-review/blob/main/cmd/opencodereview/delegate_cmd.go). It then diffs the head commit against this base, capturing exactly the changes introduced by the pull request.

### Can OCR handle pull requests that contain merge commits?

Yes. When processing merge commits, the diff generator in [`internal/diff/git.go`](https://github.com/alibaba/open-code-review/blob/main/internal/diff/git.go) uses the `--diff-merges=first-parent` flag. This renders the merge commit as changes relative to the mainline parent, ensuring the review focuses only on the feature branch's unique contributions rather than the entire merged history.

### Is it safe to run OCR on pull requests from untrusted contributors?

Yes. The tool performs validation in `validateReviewRefs` to reject references starting with hyphens, preventing command injection. Additionally, because OCR only reads from the repository and never writes or merges, it cannot be used to alter repository state even if provided with malicious inputs.