Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

So I've forked someone else's repository, made a few changes, submitted a pull request, and my changes made it into the product. Great!

But...what should I do with my forked repository? Is there a compelling reason for me to keep my repository around, or should I go ahead and delete it? I don't plan on making any additional contributions, but if I change my mind I assume I can always just re-fork it.

I'm not really concerned about keeping a backup. I'm more worried about breaking links, losing commit messages, etc.

share|improve this question
Please delete it or github will run out of hashes. – Alison Mar 24 '11 at 16:49
duplicate code is evil. And that also goes across git boundaries. – stijn Mar 24 '11 at 17:11
@stijn - I read this more as "backup" than "duplicate". And I don't think I've ever heard anyone argue that backup code is evil ... – Beekguk Mar 24 '11 at 18:15
Delete it. After all, you can always download the last state (which is the one you will want to continue working from anyway) from the project repo. – Rook Mar 24 '11 at 21:17
up vote 106 down vote accepted

If your pull request got accepted and you haven't made any other changes that you might use personally, you should delete it.

  1. Deleting doesn't harm anything.
  2. You can always refork if you need to
  3. It cuts down on useless repos in search results when people are searching for something
  4. If you use your GitHub as a sort of resume for potential jobs/contracts, it looks better if you don't have dozens of forked repos that you're not currently working on. You'll appear more efficient.
  5. It helps your own sanity when you don't have to page through hundreds of useless repos.
  6. Its better for GitHub. :)
share|improve this answer
The only downside to this is that the pull request will then show "merged commit <commit> into <repo> from unknown repository on <date>", which is a bit odd. – PLPeeters May 7 '15 at 14:53
@PLPeeters, Actually that's a pretty big downside. – Pacerier Aug 13 '15 at 10:05
I suggest using remove-github-forks to "Delete all forks that have no commits that are not in the main repository." Works like a charm. – Mar 7 at 8:07
Deleting a fork will remove that fork from being reflected to by 'Repositories you contribute to' list. On the upside deleting an unused fork makes it faster for Github for Mac to autocomplete which repo you want to clone down from your profile. – Steve Moser Mar 23 at 13:20
@SteveMoser I may be wrong, but I think you still keep the "Repositories you contributed to" list. I had one I removed every connection between and it still stayed there somehow, but might of been a fluke :P – Mark Pieszak Apr 11 at 18:10

You can delete your fork as soon as you send your Pull Request (regardless if it's merged or not). This is because GitHub stores all Pull Requests in the upstream repository, so the proposed changes can be tracked even if the fork is deleted.

That simplifies the decision.

Biggest reason for keeping your fork:

  • You're not done contributing and plan on opening more Pull Requests soon

Biggest reason for deleting your fork:

  • Unless you like hoarding, throw that shit out once you're done
share|improve this answer

I would probably tar/gzip it and put in an archive dir, then delete it 3 years later. ;) Honestly If you don't intend to work on it again for the next few months and have not used it in a while I think it would be safe to delete it.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.