698

I forked someone's repository on GitHub and would like to update my version with commits and updates made in the original repository. These were made after I forked my copy.

How can I pull in the changes that were made in the origin and incorporate them into my repository?

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
why
  • 21,267
  • 27
  • 91
  • 134
  • 1
    Possible duplicate, or maybe just related: [Merging between forks in GitHub](http://stackoverflow.com/questions/1123344/merging-between-forks-in-github). –  Jul 14 '13 at 16:42
  • In case there are additional tags you may want to sync, do `git push --force origin --tags` after the proposed solutions! – MediaVince Apr 05 '17 at 11:05
  • 1
    Possible duplicate of [How do I update a GitHub forked repository?](https://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository) – Ciro Santilli新疆棉花TRUMP BAN BAD Jun 16 '18 at 21:33
  • 1
    Very old but still: the question is unclear, don't know if @why was asking about pulling in changes from the primary repo to the fork via the GitHub web UI, or pulling in the changes via the git command line locally. – chrisinmtown Sep 15 '20 at 14:35
  • 1
    @chrisinmtown Not sure either, but in the end, you had (at the time) to use a local repository, fetch from upstream, push to origin (your fork), as I mention in my 2010 answer below. The final result is "my repository" updated with changes made from the original repository. Nowadays, you can do it through pull-request on github.com itself. – VonC Sep 15 '20 at 14:39

8 Answers8

797

You have to add the original repository (the one you forked) as a remote.

From the GitHub documentation on forking a repository:

Screenshot of the old GitHub interface with a rectangular lens around the "Fork" button

Once the clone is complete your repo will have a remote named “origin” that points to your fork on GitHub.
Don’t let the name confuse you, this does not point to the original repo you forked from. To help you keep track of that repo we will add another remote named “upstream”:

$ cd PROJECT_NAME
$ git remote add upstream https://github.com/ORIGINAL_OWNER/ORIGINAL_REPOSITORY.git
$ git fetch upstream

# then: (like "git pull" which is fetch + merge)
$ git merge upstream/master master

# or, better, replay your local work on top of the fetched branch
# like a "git pull --rebase"
$ git rebase upstream/master

There's also a command-line tool (hub) which can facilitate the operations above.

Here's a visual of how it works:

Flowchart on the result after the commands are executed

See also "Are Git forks actually Git clones?".

Edric
  • 18,215
  • 11
  • 68
  • 81
VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • 15
    See also http://bassistance.de/2010/06/25/git-fu-updating-your-github-fork/ for a nice summary. – VonC Oct 11 '10 at 06:17
  • need to add `git merge` after `git fetch upstream` – Rakib Mar 31 '13 at 11:25
  • 3
    @syedrakib I prefer a `git rebase upstream/master`, but I have added the two possibilities in the answer. – VonC Mar 31 '13 at 12:55
  • If you have local commits, doesn't this creates ugly "Merge branch 'master' of github.com:user/repo" commits every time you try to get the updates from the upstream? You can rebase sure, but if you pushed your changes to your forked repo on github, means next time you just can't rebase without regenerating the hashes for every commit turning everything in a mess. – Pablo Olmos de Aguilera C. Jan 12 '14 at 02:15
  • 1
    @PaBLoX if you have forked a repo, you are working on *your* repo, in *your* branch: rebase and force a push: no mess involved. Even a pull request in progress would be correctly updated. – VonC Jan 12 '14 at 06:52
  • @VonC Yes, but if I try to keep update with "upstream", you can't (cleanly at least afaik) without creating `Merge branch 'master' of github.com:user/repo`. Maybe I couldn't explain myself good enough. – Pablo Olmos de Aguilera C. Jan 12 '14 at 14:14
  • 1
    @PaBLoX Not if you `pull --rebase`: no "merge branch" master there. – VonC Jan 12 '14 at 14:19
  • @VonC Maybe I am missing something... first time when I have local changes I do a `pull --rebase upstream master` (standing on my branch), my changes are moved to the tip, and changes from the upstream are there (keeping their hashes). Then I `git push` to my fork, everything fine. Next time I try to `pull --rebase` from upstream will move (again) the changes to the tip, and therefore, changing the hash. Now I am not going to be able to push into github without forcing, creating a mess. (I mean, the "don't rebase if you have a public history). – Pablo Olmos de Aguilera C. Jan 12 '14 at 17:26
  • 2
    @PaBLoX you don't create a mess: you `git push --force`, replacing the history of your branch on GitHub by your local branch you just rebased. Since only you is using sad branch, no mess is involved. – VonC Jan 12 '14 at 17:34
  • @VonC if you are using github, you assume that maybe someday someone could use your work (if not... what's the idea of pushing your modifications into a public repository?). That's the whole point of maintaining a fork, add your changes, but keep update from upstream. – Pablo Olmos de Aguilera C. Jan 12 '14 at 18:48
  • 1
    @PaBLoX nope, not for a fork, not for a branch you are using for a pull request. Rebase it without fear. That is the way to "keep update from upstream". If you have other contributors, they need to work from their own fork, not directly on your own. It is your branch, your pull request. Rebase it as many time as you need. – VonC Jan 12 '14 at 19:08
  • @VonC I understand. I mean if someone just want to follow my fork... they will have problems pulling history on my fork that will be (upstream + my changes). Since my commit hashes will be different every time I push to it. Anyway, doesn't seem a bit absurd that I'm supposed to `git push --force` every time? FWIW, the closest thing I have found is this: http://blog.bleeds.info/sofa/_design/sofa/_list/post/post-page?startkey=%5B%22Maintaining-a-Fork-With-Git%22%5D – Pablo Olmos de Aguilera C. Jan 12 '14 at 19:19
  • 1
    "doesn't seem a bit absurd that I'm supposed to git push --force every time": absolutely not. That is why your pull request would be automatically updated: to allow you to rebase and stay on stop of the upstream branch. If someone follows your fork... he/she should fork it, and rebase his/her own branch on top of yours (which is possible, and will even be easier with git 1.9: http://stackoverflow.com/a/20423029/6309) – VonC Jan 12 '14 at 19:33
  • 3
    I understand. I still think it's hard, nontrivial and non intuitive. Still it's weird that my changes will be always on top (last), while actually they were made before. The solution I posted before looks better (still nontrivial too). The problem is that commit hashes changes (obviously, since there's a new parent) and generates a lot of noise inside github when issues are being called. Still it surprise me that there isn't a way to stay update with upstream and manage your own fork without creating pointless merge commits or "lie" about the history. – Pablo Olmos de Aguilera C. Jan 12 '14 at 19:55
  • @PaBLoX "lie" about the history?? But the author date doesn't change: http://stackoverflow.com/a/6340994/6309 – VonC Jan 12 '14 at 21:14
  • @VonC my bad. You are right about that. It's weird to look at the log in commit order (like in github) and see my change was the "latest". I've read your comments in your links, I still don't like it sadly, seems too much work for something that should be simple. But I understand the "problem" it's github and the data model (in other words, not too much to do). – Pablo Olmos de Aguilera C. Jan 12 '14 at 23:45
  • Works thank you :) So "remotes" actually are used to identify forks from orginal repo ? – Sangimed Mar 21 '16 at 23:54
  • @Sangimed Yes, you can have as many remote as you want, to reference different repos. Here, that owuld be to reference the original repo which was forked. – VonC Mar 22 '16 at 06:59
  • @ChinmayaB To do what? Don't forget you are not the owner of the original repo, so you cannot push directly to it. Hence the commit pushed to the fork (which you own). – VonC Jun 16 '17 at 07:17
  • @ChinmayaB OK. Can you post that as a new question, with a clear illustration of the extra commit (the squash one?) you want to avoid. This will be clearer than buried in comments ;) – VonC Jun 16 '17 at 07:30
  • @Chi something in your case must be different. So this should be OK – VonC Jun 16 '17 at 07:41
  • Is there a way to configure this upstream from github itself and maybe some configuration to have it update on autopilot? – jxramos Oct 19 '19 at 05:39
  • 1
    @jxramos Yes, through the recent GitHub Actions (https://github.com/features/actions) (list here: https://github.com/sdras/awesome-actions). For instance: https://github.com/bdougie/fetch-upstream – VonC Oct 19 '19 at 06:16
  • @Edric Thank you for the edit: this old answer is much improved now. – VonC Dec 13 '20 at 13:53
  • 'git merge upstream/master master' will merge the upstream/master TO your local master, master? Does it matter what branch you are currently on when running this command? Are you supposed to be merging or rebasing? – ennth Feb 17 '21 at 06:36
  • @ennth I prefer switching to master first. And I usually reade, especially if I have local commits I have not pushed yet. – VonC Feb 17 '21 at 06:42
113

In addition to VonC's answer, you could tweak it to your liking even further.

After fetching from the remote branch, you would still have to merge the commits. I would replace

$ git fetch upstream

with 

$ git pull upstream master

since git pull is essentially git fetch + git merge.

Boris Däppen
  • 1,136
  • 7
  • 20
n00shie
  • 1,531
  • 1
  • 11
  • 23
  • What if I know that upstream branch doesn't have any changes to existing files, but only few resource files added - do I still need merge? – azec-pdx Dec 16 '12 at 11:54
  • 4
    Surely it will just do a fast-forward in that case – Domness May 04 '13 at 08:45
  • how does one make *upstream master* overwrite all local files (so no merge conflicts) upstream master is leading in code in this case so we trust it 100% ... have managed to do this – snh_nl Nov 03 '17 at 15:29
  • 1
    @snh_nl `git rebase upstream master` Note that this is not conflict-free if you have sufficiently diverged from `upstream/master`. See https://git-scm.com/docs/git-rebase (tl;dr: this hard resets your local master to that of upstream, and then tries to remerge all of the local commits from the point of divergence forward) – cowbert Nov 15 '17 at 21:03
83

Use:

git remote add upstream ORIGINAL_REPOSITORY_URL

This will set your upstream to the repository you forked from. Then do this:

git fetch upstream

This will fetch all the branches including master from the original repository.

Merge this data in your local master branch:

git merge upstream/master

Push the changes to your forked repository i.e. to origin:

git push origin master

Voila! You are done with the syncing the original repository.

Hussain
  • 4,349
  • 5
  • 38
  • 63
ARK
  • 2,588
  • 1
  • 24
  • 25
  • how does one make upstream master overwrite all local files (so no merge conflicts) upstream master is leading in code in this case so we trust it 100% ... have managed to do this – snh_nl Nov 03 '17 at 15:29
  • 1
    One way is to simply delete local copy, and do a fresh cloning :) – ARK Sep 12 '19 at 19:25
76

This video shows how to update a fork directly from GitHub

Steps:

  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 on switching the base. Now GitHub will compare your fork with the original, and you should see all the latest changes.
  5. Click on Create a pull request for this comparison and assign a predictable name to your pull request (e.g., Update from original).
  6. Click on Create pull request.
  7. Scroll down and click Merge pull request and finally Confirm merge. If your fork didn’t have any changes, you will be able to merge it automatically.
Cody Gray
  • 222,280
  • 47
  • 466
  • 543
Dmitry Pavlov
  • 25,557
  • 8
  • 92
  • 105
  • 3
    Unfortunately, this nice graphical method creates added noise in your fork as mentioned above in the comments for the accepted answer. Therefore the command-line method is recommended: https://help.github.com/articles/syncing-a-fork/ – Jonathan Cross Nov 14 '15 at 22:33
  • 1
    I could not find the `switching the base` option – alper May 23 '20 at 14:45
  • The Github web UI in Sep 2020 has a button "Compare & Pull Request" (where previously there were separate buttons). Now it has a link "compare across branches" that I had to use. So a fetch-and merge (i.e., pull) action to get updates from master into fork can be done but not by these instructions. And even tho it's a fast forward, it clutters the history. – chrisinmtown Sep 15 '20 at 14:20
6

If you want to do it without cli, you can do it fully on Github website.

  1. Go to your fork repository.
  2. Click on New pull request.
  3. Make sure to set your fork as the base repository, and the original (upstream) repository as head repository. Usually you only want to sync the master branch.
  4. Create new pull request.
  5. Select the arrow to the right of the merging button, and make sure to choose rebase instead of merge. Then click the button. This way, it will not produce unnecessary merge commit.
  6. Done.
cakraww
  • 1,520
  • 21
  • 22
1

If you're using the GitHub desktop application, there is a synchronise button on the top right corner. Click on it then Update from <original repo> near top left.

If there are no changes to be synchronised, this will be inactive.

Here are some screenshots to make this easy.

Peter Mortensen
  • 28,342
  • 21
  • 95
  • 123
sudo bangbang
  • 19,198
  • 7
  • 64
  • 71
1

If there is nothing to lose you could also just delete your fork just go to settings... go to danger zone section below and click delete repository. It will ask you to input the repository name and your password after. After that you just fork the original again.

Chan
  • 43
  • 6
0

To automatically sync your forked repository with the parent repository, you could use the Pull App on GitHub.

Refer to the Readme for more details.

For advanced setup where you want to preserve your changes done to the forked repository, refer to my answer on a similar question here.

Saurabh P Bhandari
  • 4,338
  • 1
  • 7
  • 34