> For the complete documentation index, see [llms.txt](https://docs.sonarsource.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sonarsource.com/sonarqube-server/10.8/analyzing-source-code/pull-request-analysis/introduction.md).
# Introduction
SonarQube Server 10.8 supports pull request analysis: analysis results only include issues that have been introduced by the pull request itself.
{% hint style="info" %}
**For AI agents:** You're in the SonarQube Server 10.8 documentation. For a list of all 10.8 pages, see the [SonarQube Server 10.8 page index](https://312504542-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FiJj3TXBdWssTGGg8qK5I%2Fuploads%2FmeJ1nVNGPezOurNrTy4A%2Fsonarqube-server-10.8-llms.txt?alt=media). For the whole site, see the [page index](https://docs.sonarsource.com/llms.txt) or the [full text](https://docs.sonarsource.com/llms-full.txt). For another version, replace 10.8 in the URL with that version. The [latest version](https://docs.sonarsource.com/sonarqube-server/) has no version number in its URL.
{% endhint %}
\*Pull request analysis is available starting in [*Developer Edition*](https://www.sonarsource.com/plans-and-pricing/developer/). \*
A pull request analysis occurs when a pull request is opened and every time a change is pushed to the pull request branch. Analysis results only include issues that have been introduced by the pull request itself. A quality gate on the pull request uses these results to ensure that the code changes introduced are always clean.
The pull request analysis must be integrated into a CI pipeline. For more information, see **Integration into your CI pipeline** on the [SonarQube Server analysis overview](/sonarqube-server/10.8/analyzing-source-code/analysis-overview.md) page.
{% hint style="info" %}
The term *pull request* is used by most repository providers. GitLab, however, uses the term "merge request". Both terms refer to the same functionality and are handled equivalently in Sonar products. In our documentation, any use of the term *pull request* applies equally to GitLab merge requests.
{% endhint %}
## Improving code quality
The Quality Gate of your project is used for the pull request analyses. Only the Quality Gate’s conditions applying to new code metrics are used.
In a pull request analysis, new code is defined as the code that has changed in the pull request branch compared to the target branch. Only issues on new code are reported.
{% hint style="warning" %}
* Due to its mechanism for identifying issues on new code, pull request analysis doesn’t report issues raised at the file level.
* During a pull request analysis, new issues on old code are not reported since only new code issues are reported (For more information, see **Issue backdating (new issues on old code)** in [Issue management solution](/sonarqube-server/10.8/user-guide/issues/solution-overview.md).). It means that the first analysis on the target branch after the merge may report new issues on old code that were not reported by the pull request analysis.
{% endhint %}
{% hint style="info" %}
To get valuable results when performing a pull request analysis, the target branch should have been analyzed first.
{% endhint %}
## Quality gate status report (pull request decoration)
The pull request analysis results and quality gate status can be reported directly to your DevOps platform’s interface.
## Incremental pull request analysis
To shorten the pull request analysis, different [Introduction](/sonarqube-server/10.8/analyzing-source-code/incremental-analysis/introduction.md) are used.
## Issue synchronization
SonarQube Server synchronizes issue attributes (status, assignee, change log, comments) between the pull request and the target branch. For more information, see the corresponding section in [Issue management solution](/sonarqube-server/10.8/user-guide/issues/solution-overview.md). Note that security hotspots are not synchronized.
## Related pages
* [Setting up the pull request analysis](/sonarqube-server/10.8/analyzing-source-code/pull-request-analysis/setting-up-the-pull-request-analysis.md)
* [Maintaining project branches](/sonarqube-server/10.8/project-administration/maintaining-the-branches-of-your-project.md).
* [Introduction](/sonarqube-server/10.8/analyzing-source-code/incremental-analysis/introduction.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.sonarsource.com/sonarqube-server/10.8/analyzing-source-code/pull-request-analysis/introduction.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.