Skip to content

Instantly share code, notes, and snippets.

@kaadmy

kaadmy/git_rebase.md

Last active July 25, 2017 04:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kaadmy/aa1545c77b3db87ac6d82aa7dd467e2b to your computer and use it in GitHub Desktop.
Save kaadmy/aa1545c77b3db87ac6d82aa7dd467e2b to your computer and use it in GitHub Desktop.
Download ZIP
Git rebase
Raw
git_rebase.md

Copied from a Stackoverflow answer for posterity

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, such as upstream/master:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment