# How to prepare a clean pull request from a fork that has diverged from its upstream repository

DevFeed: [How to prepare a clean pull request from a fork that has diverged from its upstream repository](<https://devfeed.tech/articles/when-pull-requests-get-tricky-35550.md>)

Original publisher: [Read original article](<https://meowni.ca/posts/tricky-pull-requests/>)

Author: Monica Dinculescu

Published: 2014-02-25T00:00:00Z

Content type: tutorial

Language: en

Sources: [Monica Dinculescu](<https://devfeed.tech/sources/monica-dinculescu.md>)

Topics: [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [Git](<https://devfeed.tech/topics/git.md>), [Code](<https://devfeed.tech/topics/code.md>)

Tags: [branch](<https://devfeed.tech/tags/branch.md>), [changes](<https://devfeed.tech/tags/changes.md>), [future](<https://devfeed.tech/tags/future.md>), [git](<https://devfeed.tech/tags/git.md>), [merge](<https://devfeed.tech/tags/merge.md>), [pull-requests](<https://devfeed.tech/tags/pull-requests.md>), [test](<https://devfeed.tech/tags/test.md>)

## AI overview

This tutorial explains how to create a clean pull request when a fork has diverged from its upstream repository. It covers configuring an upstream remote, creating a branch from an earlier synchronized commit, reapplying or selectively extracting changes, merging upstream changes, testing, and uploading the branch.

## Source excerpt

Imagine this: you have forked a repo a long time ago and have since been in a happily committed relationship with the master branch, modifying files and committing from the hip. In case you have doubts about the likelihood of this scenario, we're talking about my notwaldorf.github.com blog branch, which I forked from holman/left. All my changes are on the master branch so that GitHub can do its magic gh-pages trick and just Make Things Work™. This could also happen for repos you've forked and mucked around with, but never thought you'd ever contribute to. Because you're a good open sorcerer, you might, at some point, want to send a pull request to fix a thing in the original repo. If you're anything like I am, you are now in a bit of a terrible situation because your fork's tip of tree has advanced and diverged quite a bit from the upstream repo, so any pull requests you send out will be polluted with code that doesn't belong in them. At this point, you probably have some regrets. Let's not dwell on them. Here's the set of steps that will help you navigate this minefield you find yourself in. They're not special; I just couldn't find them all in one place, and wanted a summary for the future. Kamal figured most of this out, because he is a git wizard, while I am, most definitely, not. Set up your upstream If git remote doesn't show you a branch called upstream, you need to add one: git remote add upstream https://github.com/user/repo_you_forked.git Set up a clean branch for your fix Step into your tardis and branch from when you were last in sync with the upstream. In my case, this was when I initially created my fork. A dull perusing of git log or git reflog should point you to the right sha. Then, git checkout -b pr_branch git reset --hard sha_from_the_past Get your changes in Here you have two options. If your changes are tiny, or you know exactly what they are, you can just manually reapply them. And by that I mean copy paste the changes into the right files, li