Pull new updates from original GitHub repository into forked GitHub repository

Question

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?

Sternutatory

Possible duplicate, or maybe just related: Merging between forks in GitHub. – Remmer

In case there are additional tags you may want to sync, do git push --force origin --tags after the proposed solutions! – Haruspex

Possible duplicate of How do I update a GitHub forked repository? – Exponential

Very old but still: the question is unclear, don't know if @Sternutatory 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. – Knisley

@Knisley 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. – Hormuz

Here's how to do it using either the web UI or the command line. – Cytolysis

if you're using GitHub Desktop, you can use it from the "History" tab in the application. Reference: https://mcmap.net/q/13852/-how-do-i-update-or-sync-a-forked-repository-on-github – Paleozoology

Answer 1

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

From the GitHub documentation on forking a repository:

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 (gh) which can facilitate the operations above.

Here's a visual of how it works:

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

Hormuz

See also bassistance.de/2010/06/25/git-fu-updating-your-github-fork for a nice summary. – Hormuz

need to add git merge after git fetch upstream – Kato

@syedrakib I prefer a git rebase upstream/master, but I have added the two possibilities in the answer. – Hormuz

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. – Clump

@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. – Hormuz

@Hormuz 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. – Clump

@PaBLoX Not if you pull --rebase: no "merge branch" master there. – Hormuz

@Hormuz 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). – Clump

@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. – Hormuz

@Hormuz 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. – Clump

@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. – Hormuz

@Hormuz 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: blog.bleeds.info/sofa/_design/sofa/_list/post/… – Clump

"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: https://mcmap.net/q/12044/-how-do-i-recover-resynchronise-after-someone-pushes-a-rebase-or-a-reset-to-a-published-branch) – Hormuz

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. – Clump

@PaBLoX "lie" about the history?? But the author date doesn't change: https://mcmap.net/q/12748/-git-rebase-without-changing-commit-timestamps – Hormuz

@Hormuz 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). – Clump

Works thank you :) So "remotes" actually are used to identify forks from orginal repo ? – Crawl

@Crawl 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. – Hormuz

@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). – Hormuz

@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 ;) – Hormuz

Is there a way to configure this upstream from github itself and maybe some configuration to have it update on autopilot? – Raleighraley

@Raleighraley Yes, through the recent GitHub Actions (github.com/features/actions) (list here: github.com/sdras/awesome-actions). For instance: github.com/bdougie/fetch-upstream – Hormuz

'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? – Coquillage

@ennth I prefer switching to master first. And I usually reade, especially if I have local commits I have not pushed yet. – Hormuz

Intriguingly, this updates Fork from Local after updating Local from Original. Is there a way to update Fork from Original, then update local from Fork? – Doorpost

@BerndWechner You can use the "Sync fork" button for that (update Fork from Original), follow by a simple git pull locally. – Hormuz

Yep, that's what I already do. But involves an exclusion into the browser. I wondered if there is a git CLI way to say the same, basically pull from one remote to another remote. – Doorpost

@BerndWechner Sure thing: gh repo sync – Hormuz

Answer 2

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.

Transmigrant

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? – Hummocky

Surely it will just do a fast-forward in that case – Calondra

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 – Huey

@Huey git rebase upstream master Note that this is not conflict-free if you have sufficiently diverged from upstream/master. See 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) – Cheese

Answer 3

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.

Orphrey

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 – Huey

Answer 4

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.

Renferd

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: help.github.com/articles/syncing-a-fork – Unlatch

I could not find the switching the base option – Sequential

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. – Knisley

Answer 5

If you want to do it without cli, you can do it fully on the 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 a head repository. Usually, you only want to sync the master branch.
4. Create a new pull request.
5. Select the arrow to the right of the merging button, and make sure choose to rebase instead of merge. Then click the button. This way, it will not produce unnecessary merge commit.
6. Done.

Subsistent

Answer 6

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.

Hillock

Answer 7

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.

Basketball

Answer 8

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.

Invalid