I was trying to compare changes I made to a forked repo.
To make this real, here is the example:
I forked https://github.com/springframeworkguru/sfg-di as https://github.com/steranka/udemy-sfg-di.
I got a local copy of the (forked) repo git clone git#github.com:steranka/udemy-sfg-di.git
I changed to the branch I wanted to work on git checkout property-source.
Made changes and committed the changes (to my local repo).
Push my changes to my fork so the changes can be compared to the original repo. git push
Now I want to compare my changes to the equivalent branch on the original repo.
The origin and upstream are set to:
origin: git#github.com:steranka/udemy-sfg-di.git
upstream: git#github.com:springframeworkguru/sfg-di.git
Searching for solution
My searches indicated that there was not a built in way to do this using the git CLI, nor the github website.
What I did find was:
https://stackoverflow.com/a/66613981/3281336. Basically do the compares via local repo.
How to compare a local Git branch with its remote branch - How to compare local vs remote branch. Later, I learned this is basically what a forked repo is... Just another remote.
General info about forks (from GitHub.com) https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests - The GitHub.com docs indicate that this is doable if you create a pull request. This is not what I want to do.
My question
How do you do this? I ran across gh-cli which might do it.
Can this be done via the github.com web interface? If so, how?
Append /compare to the URL of your repo. Example (try it):
https://github.com/mattneub/amperfy/compare
That's a public fork of a public upstream. You can select two branches, possibly at the two different repos, to see the diff.
I've selected the answer from Matt because that is the answer I was looking for. But another possible solution is based on #torek's answer.
The solution is to pull the upstream repo's branch that you want to compare locally and then do normal git diff commands. The result is that the compares are done via my local repo.
The steps to do this are:
Setup the pointers to the upstream (the repo you forked)
Get the upstream source and put it into your local repo
Compare the upstream source's (local copy) to your code.
The code commands to do this are:
git remote add upstream git#github.com:springframeworkguru/sfg-di.git
git fetch upstream property-source
git diff upstream/property-source..
This turned out to be simpler than I expected.
One benefit of this approach over the GITHUB web ui is I could compare my code changes without pushing my code to the github.
I have a CMS theme installed on my machine. I'm tracking changes to it via git
and decided to back it up on GitHub so I could share those changes.
The theme as provided is also available on GitHub. On my machine I have added
this as a remote upstream. Now I can easily see the changes between my master
and the remote upstream by using the following command:
git diff --color master upstream/number
If I could add the remote upstream on GitHub I could easily share these changes.
Is it possible to set this relationship on GitHub?
I have tried the following:
git push -u origin upstreambranch
which adds an upstreambranch to the master on GitHub. However trying to
compare both branches doesn't work, the result I get on GitHub is that: "There
isn't anything to compare"
Is there an alternative way to compare these?
If the problem is "main and master are entirely different commit histories.", the following will work
git checkout master
git branch main master -f
git checkout main
git push origin main -f
The Short Answer
It looks like GitHub won't let you compare the branches because they don't
actually share any of the same history at all, even though they may share
much of the same files and code.
Here is a screenshot of the temporary fork I made of your repo, where I tried to
compare master with the upstreambranch, like you described. Notice the error
message:
It says:
There isn't anything to compare.
master and upstreambranch are entirely different commit histories.
The Long Answer
You probably downloaded the original source and added it to a completely new
repo instead of cloning the original repo, right? Doing that will make it so
that the history of your repo will be completely different from the
history of the original repo, since your new repo won't have any of the same
commits with the same sha IDs.
You can see that by doing a reverse log of your master branch and the
upstreambranch:
# Your first commit, see commit sha
git log --reverse master
commit c548d7b1b16b0350d7fbdb3ff1cfedcb38051397 # <== HERE
Author: Padraic Stack <padraic.stack#nuim.ie>
Date: Wed Apr 2 15:11:28 2014 +0100
First commit of everything
# First commit sha of the original repo
git log --reverse upstreambranch
commit 105a12817234033c45b4dc7522ff3103f473a862 # <== THERE
Author: Jeremy Boggs <jeremy#clioweb.org>
Date: Mon Feb 22 16:00:53 2010 +0000
Creates repo directories for the Seasons theme.
Solutions
If you redo your commits on top of the original history, you should then be able
to compare the branches. There are several different ways that you can redo your
commits, including
git rebase --onto
and
git cherry-pick
You also can redo each commit manually, if you have to.
I had a similar situation, where my master branch and the develop branch I was trying to merge had different commit histories. None of the above solutions worked for me. What did the trick was:
Starting from master:
git branch new_branch
git checkout new_branch
git merge develop --allow-unrelated-histories
Now in the new_branch, there are all the things from develop and I can easily merge into master, or create a pull request, as they now share the same commit hisotry.
I solve my issue using these commands
git checkout [BRANCH]
git branch master [BRANCH] -f
git checkout master
git push origin master -f
You can force update your master branch as follows:
git checkout upstreambranch
git branch master upstreambranch -f
git checkout master
git push origin master -f
For the ones who have problem to merge into main branch (Which is the new default one in Github) you can use the following:
git checkout master
git branch main master -f
git checkout main
git push origin main -f
The following command will force both branches to have the same history:
git branch [Branch1] [Branch2] -f
From the experiment branch
git rebase master
git push -f origin <experiment-branch>
This creates a common commit history to be able to compare both branches.
This looks like undesirable behavior on github's part, but it's fairly easy to fix. What you want to do is to rebase your branch on a reasonable (any reasonable) commit in the existing history. What you can do is to fetch the github repo and find which tree in its history is most similar to the one you started with. Start this way:
git remote add github u://r/l
git fetch github
myroot=`git rev-list master --max-parents=0`
root_tree=`git rev-parse $myroot^{tree}`
github_base=`git log --pretty=%H\ %T github/master | sed -n "s/$root_tree//p"`
With any luck, that will find you a commit in the github history that has the exact tree you started with. Assuming it does,
git rebase --onto $github_base $myroot master
and you're done.
If that doesn't find a matching tree, you get to find a nearest approximation. Here's one way to get a rough estimate of the differences:
git log --pretty='echo %H $(git diff-tree -p -b -U0 '$myroot:' %T|wc -l)' github/master \
| sh
which will count the lines in a minimized diff between the tree of each commit in the github/master history and your root tree. It seems reasonable to hope for a nice small difference, you could eyeball the actual diffs on it before calling that the github_base commit and doing the rebase above.
Terminology
First, let's get some terminology out of the way...
upstream <= The remote git repo (likely whose master or release branch is in production)
forked-repo <= The remote [experimental git repo] (https://docs.github.com/en/github/getting-started-with-github/fork-a-repo) also known as "origin".
local repo <= The files and directories that you work with on your local workstaion, which you likely got by running a git clone my-forked-repo.git command
local index <= Also known as your local git "stage", i.e., where you stage your files before pushing them to you remote repo.
Github workflow process
Next, let's talk about the process of getting your changes to the upstream repo:
The process is generally to work on a feature branch and then push said branch, and open a Pull Request, either to your forked-repo's master branch or to the upstream's master branch
Create a feature branch by running git checkout -b FEATURE_BRANCH_NAME
Add/delete/modify files project files.
Add files by running git add .
Commit your files to your index by running git commit -m'My commit message'
Push your staged files by running git push origin FEATURE_BRANCH_NAME
Solution for entirely different commit histories
The master and upstreambranch are entirely different commit histories message can occur when you've forked a git repository and have changed your git history.
For example, if you fork a repo and pull your forked repo to work on it locally...
If then you decide to rewrite the entire application and then decide it's a good idea to deleting all existing files, including the forked-repo's .git directory. You add new files and directories to recreate your app and also recreate your .git directory with git init command.
Now, your application works great with your new files and you want to get it merged into the upstream repo. However, when you push your changes you get that "...entirely different commit histories..." error message.
You'll see that your original git commit will be different in your new local directory and if in your remote fork (as well as your upstream). Check this out by running this command in your current directory: git log --reverse master. Then running the following: pushd $(mktemp -d); git clone https://github.com/my-forking-username/my-forked-repo.git; git log --reverse master; popd
You must fix your local .git repo to match your remote my-forked-repo if you want to push your commits and subsequently perform a pull request (in hopes of merging your new updates to the upstream/master branch).
git clone https://github.com/my-forking-username/my-forked-repo.git
cd my-forked-repo
git checkout -b my-new-files-branch-name
# Delete all files and directories except for the .git directory
git add .
git commit -m'Remove old files'
# Copy your new files to this my-forked-repo directory
git add .
git commit -m'Add new files'
git push origin my-new-files-branch-name
Create a PR on GitHub and request to merge your my-new-files-branch-name branch in your my-forked-repo into master.
Note: The "...entirely different commit histories..." error message can also occur in non-forked repos for the same reasons and can be fixed with the same solution above.
A more simple approach where you can't mingle with the master.
Consider i have master and JIRA-1234 branch and when i am trying to merge JIRA-1234 to master i am getting the above issue so please follow below steps:-
From JIRA-1234 cut a branch JIRA-1234-rebase (Its a temp branch and can have any name. I have taken JIRA-1234-rebase to be meaningful.)
git checkout JIRA-1234
git checkout -b JIRA-1234-rebase
The above command will create a new branch JIRA-1234-rebase and will checkout it.
Now we will rebase our master.
git rebase master (This is executed in the same branch JIRA-1234-rebase)
You will see a window showing the commit history from first commit till the last commit on JIRA-1234-rebase. So if we have 98 commits then it will rebase them 1 by 1 and you will see something like 1/98.
Here we just need to pick the commit we want so if you want this commit then don't do anything and just HIT Esc then :q! and HIT ENTER.
There would be some changes in case of conflict and you need to resolve this conflict and then add the files by
git add <FILE_NAME>.
Now do git rebase continue it will take you to rebase 2/98 and similarly you have to go through all the 98 commits and resolve all of them and remeber we need to add the files in each commit.
Finally you can now push these commits and then raise Pull Request by
git push or git push origin JIRA-1234-rebase
This happened for me because I created a repo from GH, but then I also added a README. In doing so I created a commit on my remote.
Then I went and created a new repo locally, made some changes and committed. Then I pushed it to the 👆repo and tried to make a Pull Request.
But my remote's initial commit was different from my local's commit, hence this error message. GitHub itself even warns you against this:
Create a new repository on GitHub.com. To avoid errors, do not initialize the new repository with README, license, or gitignore files. You can add these files after your project has been pushed to GitHub.
GitHub Docs
Similarly if you're creating a new repo, GitHub will quietly suggest that you skip initializing the repo. Rather just define the repo.
tldr the very first commit has to be identical, you can't merge 2 commits that don't have an identical initial commit.
If you know from which commit issue started, you can reset your branch to that commit and then merge them.
this is 100% works in any situation :
1)create new folder in your machine
2)clone the remote repository to the new folder
3)delete all files and folders except for the .git folder
4)add your project files that you are working on to this new folder you created
5)open terminal
6)cd new_folder_path (path to the new folder you created)
warning : don't type > git init
7) > git add .
8) > git commit -m "write anything"
9) > git push URL(url of the remote repository)local_branch_name:remote_branch_name
This happened with me yesterday cause I downloaded the code from original repo and try to pushed it on my forked repo, spend so much time on searching for solving "Unable to push error" and pushed it forcefully.
Solution:
Simply Refork the repo by deleting previous one and clone the repo from forked repo to the new folder.
Replace the file with old one in new folder and push it to repo and do a new pull request.
I solved that problem. In my case when i did “git clone” in one directory of my choice without do “git init” inside of that repository. Then I moved in to the cloned repository, where already have a “.git” (is a git repository i.e. do not need a “git init”) and finally I started do my changes or anything.
It probably doesn’t solve the problem but shows you how to avoid it.
The command git clone should be a “cd” command imbued if no submodule exists.
I got this error when initializing a GitHub repository with a README file, and then trying to push my existing local git repository to it. This resulted in a main branch with the README file, which was the Default branch, and a master branch with my code, and they couldn't be merged.
But since I didn't actually have anything important in my main branch (if you need to keep the data from both your branches, check out PaianuVlad23's Answer instead), I managed to solve the problem by changing the Default branch to the master branch, and then delete the main branch, like this:
When in GitHub, click your user icon in the top right of the window.
Choose "Your repositories", and then click your repository name.
Under the repository name, choose the tab "Settings".
From the pane on the left, choose "Branches".
Under the headline "Default", change the default branch from the one you want to delete (in my case main) to the one you want to keep (in my case master).
Now, click the tab "Code" under the repo name.
Under the tab line containing "Code" etc, you'll see a place where it says "2 branches". Click it.
Find the branch you want to delete, and click the trash bin icon on the right on that line.
Now, your repository has only one branch, which is the one you want to push your local changes to! 🙂 Just as if you hadn't initiated your repository before pushing to it, as #mfaani's answer in this thread suggests you do it.
I found that none of the answers provided actually worked for me; what actually worked for me is to do:
git push --set-upstream origin *BRANCHNAME*
After creating a new branch, then it gets tracked properly. (I have Git 2.7.4)
I don't think we have same case here, but still someone else may find it helpful.
When similar error occurred to me, it was going to be the first merge and first commit. There was nothing in on-line repository.
Therefore, there was no code on git-hub, to compare with.
I simply deleted the empty repository and created new one with same name.
And then there was no error.
I got this error message, because I was migrating an application from SVN to GitHub and it's not enough to invoke a git init in the location of the source code checked out from SVN, but you need to invoke a git svn clone in order to have all the commit history.
This way the two source codes on GitHub will have a mutual history and I was able to open pull requests.
I had an issue where I was pushing to my remote repo from a local repo that didn't match up with history of remote. This is what worked for me.
I cloned my repo locally so I knew I was working with fresh copy of repo:
git clone Your_REPO_URL_HERE.git
Switch to the branch you are trying to get into the remote:
git checkout Your_BRANCH_NAME_HERE
Add the remote of the original:
git remote add upstream Your_REMOTE_REPO_URL_HERE.git
Do a git fetch and git pull:
git fetch --all
git pull upstream Your_BRANCH_NAME_HERE
If you have merge conflicts, resolve them with
git mergetool kdiff3
or other merge tool of your choice.
Once conflicts are resolved and saved. Commit and push changes.
Now go to the gitub.com repo of the original and attempt to create a pull request. You should have option to create pull request and not see the "Nothing to compare, branches are entirely different commit histories"
Note: You may need to choose compare across forks for your pull request.
Top guy is probably right that you downloaded instead of cloning the repo at start.
Here is a easy solution without getting too technical.
In a new editor window, clone your repo in another directory.
Make a new branch.
Then copy from your your edited editor window into your new repo by copy paste.
Make sure that all your edits are copied over by looking at your older github branch.
I had mine solved by overriding the branch:
My case: I wanted to override whatever code is in the develop with version_2.
delete the local copy of conflicting branch:
git checkout version_2
git branch -D develop
checkout a fresh branch from the version_2 and force push to git:
git checkout -b `develop`
git push origin `develop`
I didn't need to rebase. But in my case, I didn't need to take code from my old code.
first: pull from remote repo
merge or rebase
finally: push to remote repo
finish
When you are pull/merging feature to main and are in the main branch in the terminal, I successfully used 'git pull origin feature --allow-unrelated-histories'.
Before using this command, I had the same message about completely different commit histories, and I think it's because I accidentally pushed to main after committing to the feature branch. Then I tried some of the solutions offered here like rebase, which allowed me to merge my code, but I still had the compare and pull notifications through git, and it was a one time fix. By one time fix I mean I still got the different commit history message the next time I tried to merge a feature branch's code to main.
Another source from a google search offered the --allow-unrelated-histories fix, and it permanently works exactly how I wanted it to. The branches were merged and now I can merge without error messages and the compare and pull notifications work through git.
I'm sure there are consequences for people who didn't have the same problem as me, but I didn't lose any code and now my repo is clean. Also, I'm also an amateur coder and the question is older so maybe this command wasn't available when the question was asked or I'm not understanding the issue correctly.
I wanted to copy commit history of "master" branch & overwrite the commit history of "main" branch .
The steps are:-
git checkout master
git branch main master -f
git checkout main
git push
To delete master branch:-
a. Locally:-
git checkout main
git branch -d master
b. Globally:-
git push origin --delete master
The normal GitHub flow to contribute to a repo is to create a fork of the upstream, clone a local copy where you make changes, then push back up to your fork and then create a PR to have your changes merged into upstream.
But if upstream changes after that, how do you update your fork without creating a merge commit (and also without using the git CLI)?
I already know how to do this in a way that will create a merge commit or which depend on the git command line interface. This question is specifically about using the GitHub.com website or GitHub Desktop application only (no CLI).
Since this is a very common workflow it seems like there should be some simple way to do it using the GitHub GUI.
To reiterate: any answers that use the CLI or create a merge commit (e.g. this way) will not be answering this question since I'm explicitly looking for a non-CLI solution.
without a merge commit or using CLI?
Not directly with GitHub web UI alone, since it would involve rebasing your PR branch on top of upstream/master
So in short: no.
But in less short... maybe, if you really want to try it.
Rebasing through GitHub web UI is actually possible, since Sept. 2016, ...
if you are the maintainer of the original repo, wanting to integrate a PR branch
if none of the replayed commit introduces a conflict
(This differs from GitHub Desktop, which, since June 5th 2019 does support rebasing. But that is a frontend to Git CLI, like other tools provide. For example GitKraken and interactive rebase)
So a convoluted workaround would be:
to fetch, then push upstream/master to the master branch of your own fork (a CLI operation, but more on that below)
change the base branch of your current PR to master (so a PR within the same repository: your own fork), provided you haven't pushed to master.
Meaning: master in your fork represents the updated upstream/master, with upstream being the original repository that you have forked.
Since you are the owner of that repository (your fork), GitHub can then show you if you can rebase said branch to the base branch of the PR (master), but only if there is no conflict.
finally, change the base branch again, to <originalRepo>/master (which is the intended target of your PR)
The very first step is typically done through command line, but... there might be a trick to do it (update upstream master in your fork) through web UI: see "Quick Tip: Sync a Fork with the Original via GitHub’s Web UI" by Bruno Skvorc
In short, it involves:
creating a new branch from your current master (which would be at upstream/master at the time you forked the original repository)
Making a PR with that new branch and <originalRepo/master>
doing a base switch before creating the PR
That is the step which artificially forces upstream/master to be refreshed
You can the create and merge it with the “Merge Pull Request” button (and “Confirm Merge” afterwards): the merge will be trivial: no merge commit.
The end result is: your own master branch (in your fork) updated with upstream/master (the master branch of the original repository)!
You can then resume the steps I describe above, and change the base of your current PR to your own (now refreshed) master branch, and see if you can rebase it!
This is feasible with GitHub Desktop since version 1.0.7 considering the following:
If the current branch does not have any commits ahead upstream (the original repo of the fork), the new commits can be pulled without creating a new merge commit
In GitHub Desktop:
Clone your repository from File > Clone Repository
Fetch origin, which will automatically fetch the upstream as well
Go to Branches by clicking on where it says Current Branch
Click on Choose a branch to merge into <branch> at the bottom
Search for upstream/<branch>, then click Merge upstream/<branch> into <branch>
Push to origin, et voilĂ !
Otherwise, ff the current branch has commits ahead of the fork, then of course one has to create a merge commit or rebase and force push. For rebasing which might be more preferable, do the following:
In GItHub Desktop, go to Branch from menu, then Rebase Current Branch
Search for upstream/<branch>, then click Start Rebase
Solve any conflicts that have occurred from the rebase
Force push to origin. You will get a warning for this for obvious reasons.
For avoiding force-pushing to your work when your current branch is both ahead and behind its upstream counterpart, either create a new merge commit or:
Make a new branch based with all your changes
If needed, reset the original branch to its original state (before it diverged from the original repo)
Perform the steps from the first scenario and merge your changes into your branch.
And yes, it seems that pulling via the GitHub website from the original repo without creating a pull request and merge commit is not possible at this moment.
Demo GIF for first scenario: https://imgur.com/a/8wci2yf
Some GitHub issues related to this:
Add an upstream to forked repositories
multi-remote support in Desktop
Update
Note: Non-CLI based approach that might help:
Is there a way to make GitHub Desktop rebase a branch against master?
The only key here is doing a rebase, so the above answer should help.
CLI way (which is easier and using git, so it should be more comprehensive by default)
There are some practices that you should use to avoid this.
Don't work on the master branch in your fork.
$ git clone <your fork>
$ git checkout -b feature_branch
You can work in your feature_branch and then raise a Pull Request.
Once your changes are merged in the upstream master, you can pull from upstream to your origin. Since the master on upstream will have your commits sitting neatly on top of it, there won't be a merge commit.
$ git checkout master
$ git pull upstream master
$ git push origin master
In the case, where the maintainer has diverged from the master that you have in your fork, that is, it's not linear any more, you need to pull a fresh copy of it. That should not be a problem as your changes are already in the upstream.
If the master in upstream has moved ahead while you were working on your PR, then you can rebase on you feature_branch.
$ git checkout master
$ git pull upstream master
$ git push origin master
$ git checkout feature_branch
$ git rebase master
Please refer to this document for detailed reference: Fork and pull request workflow
So i have the following problem:
Back when i started programming, i FORKED a repository (using github for windows) for a browser-game. For some time now, i made stuff, did git commit and issued a pull request using the webpage.
The original author did authorize my pull request and my changes went live.
Recently, i have become an "official" author on the original repository.
So i dont want to work on my "fork" any longer but instead dev on the original.
Using github for windows, i decided to "clone" the original repo.
My github now shows my forked (AncientSion/FieryVoid) repository and the original (Aatu/FieryVoid).
Now what i would like to do is somehow "merge" my forked repo into my local clone of the original repo and from there commit to the master repo directly, that way deploying my local, not yet commited changes from my fork to the live version while at the same time getting rid of fork repository.
However, i have no idea if that works and if it does, how.
Can someone please advise ?
I don't think that the Github for Windows interface supports this, but this can definitely be done via the git bash console. This is untested, but the steps ought to be correct, since I've done something similar (identical, in fact) before. This assumes that your clone, AncientSion/FieryVoid, is up-to-date with Aatu/FieryVoid, which can be done with a pull followed by a merge, or, to avoid merge commits, with a git pull --rebase. So now you have AncientSion/FieryVoid and Aatu/FieryVoid, both present locally, with AncientSion/FieryVoid ahead of Aatu/FieryVoid by a few commits. What you need to do is pull in those commits into Aatu/FieryVoid by running the following:
cd path/to/local/clone/of/Aatu/FieryVoid
git remote add local_pull path/to/local/clone/of/AncientSion/FieryVoid
git pull local_pull master
git push origin master
Couple of assumptions:
You were working on the master branch of AncientSion/FieryVoid. If not, replace master in line 3 with your branch name.
origin is a remote that tracks the online repo Aatu/FieryVoid
I can never seem to figure out how to use git. I just do random commands and it works eventually. This is what I usually do when I want to push:
Fetch from upstream
Commit
Push to upstream
However, the above steps don't work sometimes. For example, when I do fetch from upstream, my local branch doesn't get updated.
How do I merge the remote branch into my local branch? Is there a difference between pull and fetch?
"git pull" is equivalent to "git fetch" followed by "git merge"
What you want to do is:
git commit -am "your message here"
This commits your current changes locally, and only locally. Now, assuming branch "foo":
git pull origin foo
This does a "git fetch" followed by a "git merge". Everything in this step is done to your local branch, and still has no effect on the remote branch. Depending on how your git is setup, you might need to specify the branch.
If you have a merge conflict, you will have to fix the files listed, then add them back:
git add path/to/resolved.file
When you are done, push everything you have from your local changes, to the remote server:
git push origin foo
If you pull before committing, that might cause your local branch to not be updated.
tl;dr, always commit before pulling!
Well to understand differences betwene git fetch and git pull look here.
In the simplest terms, "git pull" does a "git fetch" followed by a
"git merge".
You can do a "git fetch" at any time to update your local copy of a
remote branch. This operation never changes any of your own branches
and is safe to do without changing your working copy. I have even
heard of people running "git fetch" periodically in a cron job in the
background (although I wouldn't recommend doing this).
Working with git in eclipse might be a little bit tricky, but if you understand git basics, you should cope with it. I recommend you to read one of git tutorials, so you will be able to understand basic git operations.
The first step to learn git: Don't use egit.
Now, you are fetching and pulling from upstream. That makes me think that several people have write-access to the same repository, so we probably don't want to be doing a whole lot of merges to complicate history. It would be best to do this. I'm assuming you have already committed a changes or a set of changes to your local master branch that you want to place on the upstream repository which has been pushed to by someone else while you were making your commits.
First, we fetch the new changes but don't use them yet. This updates upstream/master to the new head of the upstream master branch.
git fetch upstream master
Now, we need to pull in these changes. This command rewrites history, and we are assuming
that you have not published your changes anywhere yet.
git rebase upstream/master master
If you have published your changes, this messier command is the one you should use (do not use both, just use this one!)
git merge upstream/master master
Now, we can push:
git push upstream master
The first two steps can be shorted to git pull --rebase and git pull for the rebase and merge versions respectively.
If you are already on the master branch, most of those second arguments are superfluous but I wrote them in for clarity. Notably, giving a second argument to git-rebase or git-merge will simply check out that branch before doing the operation. Supplying master to fetch and push is only necessary if you don't have the refs set up to automatically fetch and push master.