I recently forked a project and applied several fixes. I then created a pull request which was then accepted.
A few days later another change was made by another contributor. So my fork doesn't contain that change.
How can I get that change into my fork? Do I need to delete and re-create my fork when I have further changes to contribute? Or is there an update button?
A lot of answers end up moving your fork one commit ahead of the parent repository. This answer summarizes the steps found here which will move your fork to the same commit as the parent.
Change directory to your local repository.
git checkout master
Add the parent as a remote repository,
git remote add upstream <repo-location>
git fetch upstream
Issue
git rebase upstream/master
git status
Issue
git push origin master
For more information about these commands, refer to step 3.
Follow the below steps. I tried them and it helped me.
Checkout to your branch
Pull source repository branch for getting the latest code
When you have cloned your forked repository, go to the directory path where your clone resides and the few lines in your Git Bash Terminal.
And there you are good to go. All updated changes in the main repository will be pushed into your fork repository.
The "fetch" command is indispensable for staying up-to-date in a project: only when performing a "git fetch" will you be informed about the changes your colleagues pushed to the remote server.
You can still visit here for further queries
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: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:You only need to use the
-f
the first time after you've rebased.As a complement to this answer, I was looking for a way to update all remote branches of my cloned repo (origin) from upstream branches in one go. This is how I did it.
This assumes you have already configured an upstream remote pointing at the source repository (where origin was forked from) and have synced it with
git fetch upstream
.Then run:
The first part of this command lists all heads in the upstream remote repo and removes the SHA-1 followed by
refs/heads/
branch name prefix.Then for each of these branches, it pushes the local copy of the upstream remote tracking branch (
refs/remotes/upstream/<branch>
on local side) directly to the remote branch on origin (refs/heads/<branch>
on remote side).Any of these branch sync commands may fail for one of two reasons: either the upstream branch have been rewritten, or you have pushed commits on that branch to your fork. In the first case where you haven't committed anything to the branch on your fork it is safe to push forcefully (Add the -f switch; i.e.
git push -f
in the command above). In the other case this is normal as your fork branch have diverged and you can't expect the sync command to work until your commits have been merged back into upstream.Here is GitHub's official document on Syncing a fork: