399

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.

Improve this question
8
  • 100
    Please delete it or github will run out of hashes.
    – Armand
    Mar 24, 2011 at 16:49
  • 4
    duplicate code is evil. And that also goes across git boundaries.
    – stijn
    Mar 24, 2011 at 17:11
  • 7
    @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, 2011 at 18:15
  • 4
    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, 2011 at 21:17
  • What happens if the original repo gets deleted and no one has forks remaining? How to regain access to the repo/fork in that case?
    – Kromster
    Oct 12, 2016 at 9:01

5 Answers 5

Reset to default
82

Updated answer:

As of February 18, 2021, the “Unknown Repository” issue has been resolved. You should be ok to delete repositories once all the branches have been merged.

Old answer:

Deleting forked repositories will erase history from your Pull Requests.

PR with unknown repository

Deleting a forked repository will delete any information associated with your repository. This can retroactively affect any references to your repository, including pull requests that have already been merged. (See Pull request displays "unknown repo" after deletion of fork)

Your comments and commits should be preserved on any pull requests that were associated with your repository, but you will do so at your own risk.

However, deleting old branches after a merge is perfectly safe.

While deleting repositories should be avoided, deleting unused branches is perfectly acceptable. In fact, GitHub encourages you to delete old branches.

Tidying up after Pull Requests

At GitHub, we love to use Pull Requests all day, every day. The only trouble is that we end up with a lot of defunct branches after Pull Requests have been merged or closed. From time to time, one of us would clear out these branches with a script, but we thought it would be better to take care of this step as part of our regular workflow on GitHub.com.

Starting today, after a Pull Request has been merged, you’ll see a button to delete the lingering branch:

Delete this branch button

If the Pull Request was closed without being merged, the button will look a little different to warn you about deleting unmerged commits:

Delete branch with warning

Of course, you can only delete branches in repositories that you have push access to.

Enjoy your tidy repositories!

Alternatively, if you really don't want to keep them around, you can archive a repository to indicate it is no longer actively maintained.

See also

Improve this answer
4
236

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. :)
Improve this answer
7
  • 25
    @PLPeeters, Actually that's a pretty big downside.
    – Pacerier
    Aug 13, 2015 at 10:05
  • 5
    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.
    – fregante
    Mar 7, 2016 at 8:07
  • 3
    @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 - Trilon.io
    Apr 11, 2016 at 18:10
  • 25
    I took the risk and deleted the forked repository and my contributed list didn't get affected so I can safely say that deleting the forked repo will not affect your contribution credits
    – Amin Mohamed Ajani
    Mar 14, 2017 at 16:10
  • 4
    Archiving the repository is another option. It hides it from your list without deleting it.
    – Peter DeWeese
    Feb 23, 2018 at 14:05
95

You can delete your fork as soon as you submit a Pull Request, regardless if it's merged or not. GitHub stores all PRs in the upstream repository, meaning proposed changes are tracked even if the fork is deleted.

That simplifies the decision.

You may still want to keep the fork if:

  • You'll be contributing more right away (e.g. extend existing PR or open new PRs)

You may want to delete the fork if:

  • You want a clean portfolio of projects under your name
Improve this answer
9
  • 13
    "You can delete your fork as soon as you send your Pull Request" This is what I was looking for!
    – Unnawut
    Jan 13, 2018 at 7:31
  • Me too, but the answer starts with "If your pull request got accepted..." Did you try it :D
    – Legends
    Mar 29, 2018 at 0:17
  • 7
    Warning: When you delete your fork, the original branch name is removed from any pending pull requests. (Stevoisiak wants to merge 1 commit into Drugoy:master from unknown repository)
    – Stevoisiak
    May 1, 2018 at 13:48
  • If you delete your fork before the PR is merged, not only will "unknown repository" be displayed as mentioned in previous comment but it will also not be possible to add additional commits to the PR using your fork / branch. At least not easily and maybe not at all. This is sometimes done by repository maintainers if a PR needs some "tweaking" before merging.
    – Sybille Peters
    Jun 20, 2020 at 5:04
  • 3
    This doesn't seem to be true anymore, my pull request was automatically closed (by myself according to the pull request history) because "user closed this by deleting the head repository".
    – Esteban
    Feb 6 at 22:28
20

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.

Improve this answer
13

Just to add to the answers provided - GitHub itself recommends deleting ("tidying") forked repositories after they've been merged.

This can be done right in the pull request after merge - please see this blog post.

Furthermore, as of this moment, I don't see any downsides noticed in the comments:

  • even after deleting forked repository, there is correct message in the pull request (no "unknown repository")
  • repository to which you've contributed is still listed in your contribution activity
  • you are still listed in contributors of that repository

I would not recommend deleting it before merging as suggested by @Dennis, as you might still have to make some modifications to the code if requested by the authors.

Improve this answer
3
  • 2
    I just deleted a forked repository and the pull request now says unknown repository. Oh well.
    – Krassi
    Apr 11, 2017 at 9:22
  • 17
    Your link goes to an article explaining how to delete a branch after a successful PR merge; this question however asks about deleting a repository. You will only observe the "unknown repository" when you delete your own project fork (repository).
    – stakx
    May 24, 2017 at 11:01
  • 4
    The question is about deleting a fork, not a branch.
    – Andy
    Aug 20, 2018 at 22:59

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