Question

I’ve forked someone’s project and made some commits. I filled out a pull request, and it wasn’t accepted (either the change was not desirable, or the author rewrote the functionality to be in line with “his style”). Now I’m stuck with my local fork having a few extra commits that will never get to go into upstream. I can back out the change sets, but then I have twice as many extra commits and will have to cart them around forever. It’s just ugly!

What’s the best way to abandon these commits that nobody wants and get my fork back to tracking upstream? I know I can delete the fork completely and re-fork it, but this is really heavy-handed and I’d lose any other work I’m doing.

Answer 1

You can reset your repo state to an earlier commit. First figure out which commit you want to reset your repo to:

git log

To reset your repo to that state:

git reset --hard <commit_hash>

If you have a forked remote repo, you can push these changes back to it:

git push -f <remote> <branch>

You might want to change your workflow to make things easier in the future though.

When I fork a repo and am making my own changes to it, I first set up two remotes. One remote will point to my forked repo (ex: origin), and add another remote points to the original repo that was forked from (ex: original_repo). So I might have something like:

$ git remote
origin
original_repo

I create a branch to do all my work in, ex: feature. When making a pull request, I do it from the feature branch to the original_repo master branch. If the pull request is rejected, like your example, you can just abandon this branch. If you want to work on more modifications, just create another branch from master and use that to work in.

I also don’t commit or merge any local changes to the master branch. I only use the master branch to sync up with the original_repo master branch. ex:

git checkout master
git fetch original_repo
git merge original_repo/master

This ensures the master branch is always synched up with the original repo’s master branch. For example, if the pull request was accepted and merged in, when the fetch and merge happens, local master would also have all the ‘approved’ code used in the original repo.

Basically use master to sync up with the original repo’s master and always branch from master when you want to make edits. Use those branches for your pull requests to the original repo.