Clean up a fork and restart it from the upstream

Git

Git Problem Overview


I have forked a repository, then I made some changes and it looks like I've messed up everything.

I wish to start it again from scratch, using the current upstream/master as the base for my work.
Should I rebase my repository or delete it at all?

Git Solutions


Solution 1 - Git

The simplest solution would be (using 'upstream' as the remote name referencing the original repo forked):

git remote add upstream /url/to/original/repo
git fetch upstream
git checkout master
git reset --hard upstream/master  
git push origin master --force 

(Similar to this GitHub page, section "What should I do if I’m in a bad situation?")

Be aware that you can lose changes done on the master branch (both locally, because of the reset --hard, and on the remote side, because of the push --force).

An alternative would be, if you want to preserve your commits on master, to replay those commits on top of the current upstream/master.
Replace the reset part by a git rebase upstream/master. You will then still need to force push.
See also "What should I do if I’m in a bad situation?"


A more complete solution, backing up your current work (just in case) is detailed in "Cleanup git master branch and move some commit to new branch".

See also "Pull new updates from original GitHub repository into forked GitHub repository" for illustrating what "upstream" is.

upstream


Note: recent GitHub repos do protect the master branch against push --force.
So you will have to un-protect master first (see picture below), and then re-protect it after force-pushing).

enter image description here


Note: on GitHub specifically, there is now (February 2019) a shortcut to delete forked repos for pull requests that have been merged upstream.

Solution 2 - Git

Love VonC's answer. Here's an easy version of it for beginners.

There is a git remote called origin which I am sure you are all aware of. Basically, you can add as many remotes to a git repo as you want. So, what we can do is introduce a new remote which is the original repo not the fork. I like to call it original

Let's add original repo's to our fork as a remote.

git remote add original https://git-repo/original/original.git

Now let's fetch the original repo to make sure we have the latest coded

git fetch original

As, VonC suggested, make sure we are on the master.

git checkout master

Now to bring our fork up to speed with the latest code on original repo, all we have to do is hard reset our master branch in accordance with the original remote.

git reset --hard original/master

And you are done :)

Solution 3 - Git

Following @VonC great answer. Your GitHub company policy might not allow 'force push' on master.

remote: error: GH003: Sorry, force-pushing to master is not allowed.

If you get an error message like this one please try the following steps.

To effectively reset your fork you need to follow these steps :

git checkout master
git reset --hard upstream/master
git checkout -b tmp_master
git push origin

Open your fork on GitHub, in "Settings -> Branches -> Default branch" choose 'new_master' as the new default branch. Now you can force push on the 'master' branch :

git checkout master
git push --force origin

Then you must set back 'master' as the default branch in the GitHub settings. To delete 'tmp_master' :

git push origin --delete tmp_master
git branch -D tmp_master

Other answers warning about lossing your change still apply, be carreful.

Solution 4 - Git

How to do it 100% through the Sourcetree GUI

(Not everyone likes doing things through the git command line interface)

> Once this has been set up, you only need to do steps 7-13 from then on. > > Fetch > checkout master branch > reset to their master > Push changes to server

Steps

  1. In the menu toolbar at the top of the screen: "Repository" > "Repository settings"

  1. "Add"

  1. Go back to GitHub and copy the clone URL.

  1. Paste the url into the "URL / Path" field then give it a name that makes sense. I called it "master". Do not check the "Default remote" checkbox. You will not be able to push directly to this repository.

  1. Press "OK" and you should see it appear in your list of repositories now.

  1. Press "OK" again and you should see it appear in your list of "Remotes".

  1. Click the "Fetch" button (top left of the Source tree header area)

  1. Make sure the "Fetch from all remotes" checkbox is checked and press "ok"

  1. Double click on your "master" branch to check it out if it is not checked out already.

  2. Find the commit that you want to reset to, if you called the repo "master" you will most likely want to find the commit with the "master/master" tag on it.

Example of a commit with a

  1. Right click on the commit > "Reset current branch to this commit".

  2. In the dialog, set the "Using mode:" field to "Hard - discard all working copy changes" then press "OK" (make sure to put any changes that you don't want to lose onto a separate branch first).

  1. Click the "Push" button (top left of the Source tree header area) to upload the changes to your copy of the repo.

Your Done!

Solution 5 - Git

VonC's answer states

> Be aware that you can lose changes done on the master branch (both locally, because of the reset --hard, and on the remote side, because of the push --force).

So I'll just cover how to create a new branch in the existing fork which is tracking the main branch of the repo originally forked from.

Why this can be important: Supposing you already have another pull request submitted for a different feature from the same fork. Or anybody else has forked from your fork. Then a hard reset is bad.

Supposing the forked-from remote is called upstream.

git fetch upstream main
git switch -c upstreamb/main/track upstream/main

You will be in a new branch upstreamb/main/track

% git branch 
...
* upstreamb/main/track
% git pull upstream main
From github.com:XXXX/YYYY
 * branch                  main       -> FETCH_HEAD
Already up to date.

Notice that / in the branch name is allowed. To avoid confusion and ambiguity I have added b to upstream to indicate that it is a local branch.

Now you can create a new feature branch from track, and you can use git difftool or whatever to selectively compare and copy from the abandoned work, if necessary.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questiontampe125View Question on Stackoverflow
Solution 1 - GitVonCView Answer on Stackoverflow
Solution 2 - GitAhmad AwaisView Answer on Stackoverflow
Solution 3 - GitHugodbyView Answer on Stackoverflow
Solution 4 - GitDaniel TononView Answer on Stackoverflow
Solution 5 - GitCraig HicksView Answer on Stackoverflow