I'm working on a free project on Github. I fork it, made some changes, did a PR and everything worked ok (PR was accepted).

Then I update my fork with upstream, did some other changes, and made another PR.

Then I realised that my PR included all the commits I pushed earlier, and every file I modify, even the ones I already sent.

I made the upstream to be up to date, but I failed somewhere, or my fork, never understood that I was up to date (I even made the push).

So to avoid that, I made a branch only with the file I changed. However, the PR still want to send all the commits I made to the repo. The files in this case, are ok, only modified files are on the PR

So, what is the correct way to work with a fork?

Did I missed a step after upstream and push? or should I delete my fork after every PR and start all over again?


3 Answers 3


One useful way of handling long-term contributions from a fork could be:

  1. Never touch master. On your fork, master reflects the status on the main project.
  2. First, configure an upstream remote on your machine to the original project. You can do so by running git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git (You need to do this only once).
  3. Whenever you're doing changes, always do them on a branch. If you're working on the feature-guau branch, you do commits to it and pushes. All of that will be on your fork.
  4. Once your feature is ready, you can create a PR from yourfork/feature-guau to original-project/master (you do that on GitHub).
  5. The maintainer may ask you to do changes. Every time you work on it, you keep on pushing to your branch, and that updates your PR.
  6. Once the maintainer merges your PR, your changes are on their master, but yours is outdated.
  7. What you can do now, is "bring" their master branch from upstream. To do so, you can:
    • Run git checkout master. That switches your working copy to your master (that is outdated).
    • Run git fetch upstream. This makes your local git aware of the changes existing on upstream/master, but doesn't do any changes.
    • Run git reset --hard upstream/master. This makes your master branch point to the same commit that's on the original project. This loses any changes on your master branch, but from my 3rd point, you shouldn't have any.
    • Lastly, you can update your fork so that in GitHub, it's in sync with the original project. You can run git push -f for that (it's not advised to do so if multiple people are working on your fork... but... I understand that's not your case).

The 7th step can be done at any moment, as a way to sync your master branch with the original project. Then, you can either merge master with your branch or rebase it.

  • Instead of git reset --hard upstream/master, why not git merge --ff upstream/master(fast-forward merge)? It can achieve the same outcome (unless there's a force-push) without the hard reset.
    – zypA13510
    Commented Aug 1, 2019 at 8:08

You aren't using git branches correctly.

Essentially, you should create a branch each time you want to submit a PR, make all the changes on that branch (could be more than one patch) and push it from there. Once the PR is accepted, you should rebase your master branch from the upstream master, and when you have another idea you want to contribute, make sure your master is up to date, and create another branch from it.

  • No need to rebase the master branch when you're doing it normally, it should be a fast-forward merge. Commented Apr 13, 2018 at 12:53
  • @curiousdannii you need to fetch it. But indeed, should be fast forward.
    – Mureinik
    Commented Apr 13, 2018 at 12:54

Here are the steps you need to do to get a clean, nice pull request. I generally suggest this workflow to people with less previous exposure to git. You could make a rebase on auth repo master, but this might lead to non-trivial merging, depending on the delta. Therefore:

  1. Do not delete your fork. That was bad advice in the comments.

  2. Fetch the latest master branch from the target repo to your local clone (on your computer, not your fork).

  3. Create a new branch based on that latest official master branch

  4. Cherry-pick all the changes for your second pull request onto your new branch (ideally with git cherry-pick -n, so you can make a new nice topical commit).

  5. Push your new clean branch to your fork

  6. Make a pull request from your new clean branch on your fork to the official repo's master branch.

Yay - Now you have a pull request with only your new changes!

On a sidenote: A bit of advice for you.

Generally, you should look at your local clone for all the work. The fork is just a place where to put your finished or half-finished work so it doesn't vanish when your local computer dies, and to collaborate with others. Always start new changes based on the latest master of the official/authoritative repository. With more experience, you most likely want to rebase your changes daily on authoritative master to always keep only a small delta in order to facilitate merges and simplify your cognitive load when developing and bugfixing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.