This is video #9 in the Data School series, "Introduction to Git and GitHub." Relevant links, a command list, and the full transcript are below. Playlist: • Version control with G...
== LET'S CONNECT! ==
Blog: www.dataschool.io
Newsletter: www.dataschool.io/subscribe/
Twitter: / justmarkham
GitHub: github.com/justmarkham
== LINKS RELATED TO THIS VIDEO ==
Diagrams of forking and syncing: www.dataschool.io/simple-guide...
Syncing a fork: help.github.com/articles/sync...
Git quick reference for beginners: www.dataschool.io/git-quick-re...
== COMMAND LIST ==
show your remotes: git remote -v
add an upstream remote: git remote add upstream [URL]
fetch changes from the upstream: git fetch upstream
merge those changes into your repo: git merge upstream/master
push those changes to the origin: git push origin master
== TRANSCRIPT ==
In this video, we're going to talk about syncing your fork, what that means, and why you might want to do it.
To start, let's go through what we already know about forks. Here's a diagram from my blog, and I'll link to this in the video description. In this diagram, the top level is the GitHub level, and the bottom level is your local computer.
Remember that if you want to copy a GitHub repo, you just fork it, and then you can clone it to your local computer. After making changes and committing those changes, you can push the changes back up to GitHub. We won't cover pull requests in this video, but that's simply how you ask the owner of the original repo to pull your changes into their repo.
Anyway, let's pretend that you forked a repo yesterday, and then today, the repo owner made some changes that you want to incorporate into your fork. Remember from a previous video that forks do not automatically stay in sync, and thus you have to do this manually.
Let's look at another diagram. If you want to sync your fork with the original repo, which we call the "upstream", this actually happens through your local computer. You simply "fetch" the changes from the upstream, you "merge" them into your repo, and then you "push" them up to GitHub. Note that the "fetch" and "merge" steps are often combined into a single step called a "pull", but it's generally recommended that you fetch and merge in two separate steps.
Let's actually do this for one of my repos. Here's the commit history of a repo that I forked, and here's the commit history of my fork. You can see that the original repo has one additional commit since I forked it. I've opened Git Bash, and we're already in the working directory for that repo.
First, let's check our remotes with "git remote -v". We've got an "origin" remote, but we also need an "upstream" remote that points to the original repo. We'll copy the URL from GitHub. You'll probably be using the HTTPS URL, but I set up SSH so I'm using the SSH URL. Then we "git remote add upstream" and paste the URL using the "Insert" key on Windows. Let's check that it worked.
Now we're ready to fetch. You type "git fetch upstream", and then type your password. That command fetched the changes, and stored them in a branch called "upstream/master". You can actually switch to that branch and look at the changes if you like, but we're going to go ahead and merge those changes. You type "git merge upstream/master", which tells git to merge that branch into your working branch, which also happens to be called "master".
If you like, you can also push those changes up to GitHub, so that your GitHub repo is in sync. Just like before, we type "git push origin master", then your password, and you're done! You can see that the change is now in my repo.