I forked a project, applied several fixes and created a pull request which was 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?
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 https://github.com/whoever/whatever.git
# 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.
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.
Here is a great tutorial I found on working with github: gun.io/blog/how-to-github-fork-branch-and-pull-request
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.Another Git failure. If this tools is supposed to support distributed collaboration, then why is it so difficult to perform a basic workflow? 4 million people and 2200 upvotes mean the tool failed. "you can add the original GitHub repository as a "remote" - Why does one even have to do this? Why is it not done during the fork? What is so broken about this tool?
@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 github.com/github/hub for GitHub integration in Git.