git git-fork github repository synchronization

How do I update or sync a forked repository on GitHub?


I forked a project, made changes, and created a pull request which was accepted. New commits were later added to the repository. How do I get those commits into my fork?




In your local clone of your forked repository, you can add the original GitHub repository as a “remote”. (“Remotes” are like nicknames for the URLs of repositories – origin is one, for example.) Then you can fetch all the branches from that upstream repository, and rebase your work to continue working on the upstream version. In terms of commands that might look like:

# Add the remote, call it "upstream":

git remote add upstream

# Fetch all the branches of that remote into remote-tracking branches

git fetch upstream

# Make sure that you're on your master branch:

git checkout master

# Rewrite your master branch so that any commits of yours that
# aren't already in upstream/master are replayed on top of that
# other branch:

git rebase upstream/master

If you don’t want to rewrite the history of your master branch, (for example because other people may have cloned it) then you should replace the last command with git merge upstream/master. However, for making further pull requests that are as clean as possible, it’s probably better to rebase.

If you’ve rebased your branch onto upstream/master you may need to force the push in order to push it to your own forked repository on GitHub. You’d do that with:

git push -f origin master

You only need to use the -f the first time after you’ve rebased.


  • 116

    As your fork only exists on github, and github does not have tools for doing merges through the web interface, then the right answer is to do the upstream merge locally and push the changes back to your fork.

    Jun 19, 2012 at 3:50

  • 34

    Here is a great tutorial I found on working with github:

    Jun 19, 2012 at 3:55

  • 60

    A quick note that rather than having to rebase your own master branch to ensure you are starting with clean state, you should probably work on a separate branch and make a pull request from that. This keeps your master clean for any future merges and it stops you from having to rewrite history with -f which messes up everyone that could have cloned your version.

    May 29, 2013 at 23:09

  • 11

    Instead of the rebase command, i used the following: git merge --no-ff upstream/master This way your commits aren’t on top anymore.

    Oct 17, 2016 at 13:20

  • 29

    @jww: You ask why Git needs to be told about the original GitHub repository. It is because Git is a decentralized version control system and is not tied to GitHub in any way; it is probably obvious that Git was created before GitHub. When you create a forked repository on GitHub and clone it, GitHub knows that the repository is a fork; Git has no reason to, and does not. (Why doesn’t the clone copy the Git remotes? Git is decentralized; different people will want different remotes; it would make no sense to do this.) See for GitHub integration in Git.

    Jun 4, 2017 at 4:43


Starting in May 2014, it is possible to update a fork directly from GitHub. This still works as of September 2017, BUT it will lead to a dirty commit history.

  1. Open your fork on GitHub.
  2. Click on Pull Requests.
  3. Click on New Pull Request. By default, GitHub will compare the original with your fork, and there shouldn’t be anything to compare if you didn’t make any changes.
  4. Click switching the base if you see that link. Otherwise, manually set the base fork drop down to your fork, and the head fork to the upstream. Now GitHub will compare your fork with the original, and you should see all the latest changes.
    enter image description here
  5. Create pull request and assign a predictable name to your pull request (e.g., Update from original).
  6. Scroll down to Merge pull request, but don’t click anything yet.

Now you have three options, but each will lead to a less-than-clean commit history.

  1. The default will create an ugly merge commit.
  2. If you click the dropdown and choose “Squash and merge”, all intervening commits will be squashed into one. This is most often something you don’t want.
  3. If you click Rebase and merge, all commits will be made “with” you, the original PRs will link to your PR, and GitHub will display This branch is X commits ahead, Y commits behind <original fork>.

So yes, you can keep your repo updated with its upstream using the GitHub web UI, but doing so will sully your commit history. Stick to the command line instead – it’s easy.


  • 20

    This worked great one time. The second time this process did not work the same way: the “Switching the base” link did not show up. And when I hit “Click to create a pull request” it created a PR on the SOURCE repo. NOT what I wanted..

    Aug 21, 2014 at 18:14

  • 31

    Still works (Marchi 2015), all though the “Switching the base” link is no longer there. You have to change the “Base” drop down’s so both point to your fork and then you’ll get a prompt to “Compare across repos”, which will take you to where you want.

    Mar 4, 2015 at 14:05

  • 8

    April 2015. Works. Thanks. I did get “Switching to base”. However, step 6 was “Create pull request” -> enter comment -> “Create pull request”. End up with 1 commit ahead of original.

    – cartland

    Apr 9, 2015 at 0:08

  • 5

    @cartland (or others) – yes, it says “This branch is 1 commit ahead of …” Is this something to worry about? Is it possible to get rid of that message?

    – RenniePet

    May 15, 2015 at 22:59

  • 23

    wouldnt it be better, with a simply update or sync button!

    Jan 24, 2017 at 3:32


Here is GitHub’s official document on Syncing a fork:

Syncing a fork

The Setup

Before you can sync, you need to add a remote that points to the upstream repository. You may have done this when you originally forked.

Tip: Syncing your fork only updates your local copy of the repository; it does not update your repository on GitHub.

$ git remote -v
# List the current remotes
origin (fetch)
origin (push)

$ git remote add upstream
# Set a new remote

$ git remote -v
# Verify new remote
origin (fetch)
origin (push)
upstream (fetch)
upstream (push)


There are two steps required to sync your repository with the upstream: first you must fetch from the remote, then you must merge the desired branch into your local branch.


Fetching from the remote repository will bring in its branches and their respective commits. These are stored in your local repository under special branches.

$ git fetch upstream
# Grab the upstream remote's branches
remote: Counting objects: 75, done.
remote: Compressing objects: 100% (53/53), done.
remote: Total 62 (delta 27), reused 44 (delta 9)
Unpacking objects: 100% (62/62), done.
 * [new branch]      master     -> upstream/master

We now have the upstream’s master branch stored in a local branch, upstream/master

$ git branch -va
# List all local and remote-tracking branches
* master                  a422352 My local commit
  remotes/origin/HEAD     -> origin/master
  remotes/origin/master   a422352 My local commit
  remotes/upstream/master 5fdff0f Some upstream commit


Now that we have fetched the upstream repository, we want to merge its changes into our local branch. This will bring that branch into sync with the upstream, without losing our local changes.

$ git checkout master
# Check out our local master branch
Switched to branch 'master'

$ git merge upstream/master
# Merge upstream's master into our own
Updating a422352..5fdff0f
 README                    |    9 -------                 |    7 ++++++
 2 files changed, 7 insertions(+), 9 deletions(-)
 delete mode 100644 README
 create mode 100644

If your local branch didn’t have any unique commits, git will instead perform a “fast-forward”:

$ git merge upstream/master
Updating 34e91da..16c56ad
Fast-forward                 |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Tip: If you want to update your repository on GitHub, follow the instructions here


  • 2

    This updates my local fork, but my fork on still says “43 commits behind”. I had to use lobzik’s technique to create a pull request for myself to merge the master changes into my fork.

    Jan 23, 2015 at 17:38

  • 17

    @MichaelMcGinnis After merging locally, you would have to push your changes to github. git push origin master

    – jumpnett

    Feb 11, 2015 at 22:50

  • 1

    Might be smart to push with --follow-tags:

    – kenny

    Nov 6, 2015 at 15:19

  • 1

    I have to do it for all branches separately git merge upstream/master, then check out to develop branch and do git merge upstream/develop

    – Shobi

    May 28, 2017 at 13:02

  • 1

    This helped. The merging chapter ist important for me.

    Sep 29, 2020 at 12:14