While this may seem trivial to those that have been working in a GitHub workflow for a while, I’ve just recently been working with others through GitHub and have had to learn how to do this.
So you start with either of two scenarios:
- You cloned the original repository to your local machine
- You cloned your fork of the repository to your local machine
Regardless of which scenario you start with, you need to end up with 2 remote branches:
- origin, which points to your forked GitHub project
- upstream, which points to the original GitHub project
So to normalize so we end up with these remote branches
If Scenario #1
git remote rename origin upstream git remote add origin https://github.com/YOURUSERNAME/PROJECT.git
If Scenario #2
git remote add upstream https://github.com/ORIGINALUSER/PROJECT.git
Alright, moving on…
So any time the upstream(original) project changes you will need to synchronize your fork on github(even after you are the one that submitted the pull request and it was merged)
To do this you should be able to issue the following commands
git remote update git rebase upstream/master git push origin master
So essentially you are telling git to fetch all of your remote branches, then you are applying all changes from the upstream/master branch to your master so that both are in sync. Then you push your master up to your fork on GitHub. At the end, all 3 repositories’ master branches(local, fork, original) will be in sync.
This does assume a few things especially that you do your edits in separate branches and that your local master branch is the same as your origin/master. This is the typical development workflow(I think).