# Testing Klipper Pull Requests

**URL:** <https://klipper.discourse.group/t/testing-klipper-pull-requests/21551>\
**Category:** Knowledge Base\
**Created:** [January 22, 2025, 12:02pm UTC](https://klipper.discourse.group/t/testing-klipper-pull-requests/21551 "2025-01-22T12:02:49Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sineos](https://yyz2.discourse-cdn.com/free1/user_avatar/klipper.discourse.group/sineos/32/18_2.png) [@Sineos](https://klipper.discourse.group/u/Sineos)\
**Post date:** [January 22, 2025, 12:02pm UTC](https://klipper.discourse.group/t/testing-klipper-pull-requests/21551/1 "2025-01-22T12:02:49Z")

</div>

# Rational

New features and changes to Klipper are typically managed via [Pull Requests](https://github.com/Klipper3d/klipper/pulls) (PR) against the [Klipper main repository on GitHub](https://github.com/Klipper3d/klipper).

If one wants to evaluate individual PRs and potentially provide feedback, there is a quite easy way to integrate such changes into the Klipper that is running locally.

# Process

**1. Check the PR’s quality**  
At the bottom of the PR, an indication is displayed if the PR fulfills the general quality requirements and cleanly applies to the repository. The status should look like in the following screenshot:

 ![pr_quality](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/9/b/9b69115cba2415f3975a22535886851754ff09e9.png)

**2. Identify the PR number**  
For integrating the PR locally, its number is required. The screenshot below shows how to identify this number:

 ![pr_number](https://global.discourse-cdn.com/free1/uploads/klipper/original/3X/b/b/bb0888134dd28c6f873bcfbe246ae08fd32cb000.png)

**3. Integration of the PR locally**  
To integrate the PR in the local installation, some commands on the Linux shell are required:

```auto
sudo service klipper stop
cd ~/klipper
git fetch origin pull/<the identified PR number>/head && git checkout FETCH_HEAD
sudo service klipper start

```

With `<the identified PR number>` being the number from step 2 above.  
Taking the example from the screenshots above, the relevant command would be:

```auto
git fetch origin pull/6784/head && git checkout FETCH_HEAD

```

**4. Update in case the PR gets updated**  
It is common for PRs to evolve over time due to feedback received. To update to the latest version, repeat the procedure in step 3.

**5. Return to the previous version**  
To finish the testing and return to the previously used version, use the following commands:

```auto
sudo service klipper stop
cd ~/klipper
git checkout master
sudo service klipper start

```

# Final Notes

There are many different ways to potentially achieve the same result. Listing all these options with their differences and quirks is beyond the scope of this article.

- This approach intentionally goes the way via a _HEAD detached state_ to avoid piling up branches in the local copy.
- PRs should be tested individually. This method is not suited to stack different PRs. If different PRs need to be tested, always return to the original version before testing another PR.