你可以在GitHub上恢复/恢复已删除的分支多长时间？

Question

This is not a question on how to restore lost branches in Github, but rather how long you have to restore a deleted branch through the following user case story:

Within a pull request (often used as a place for code review) the branch can be merged and then deleted, all in the github GUI. Should you choose to delete it, you are given the option with a bold and underlined word, to "restore" the branch.

I suspect this option has a time limit and that github doesn't keep this available indefinitely.

Does github have a time limit on how long you can do this? If it does, what is that time limit?

Answer 1

I asked GitHub Support , this was their response (emphasis mine):

We use a separate ref namespace for all Pull Requests which we use for various things including restoring the branch. Since we keep those [Pull Request] refs indefinitely, there's no time limit on restoring a branch .

You can see these special references in your remote by using the following:

$ git ls-remote | grep pull
From git@github.com:<username>/<remote>.git
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa        refs/pull/1/head
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb        refs/pull/1/merge
cccccccccccccccccccccccccccccccccccccccc        refs/pull/2/head
dddddddddddddddddddddddddddddddddddddddd        refs/pull/2/merge

The references are namespaced under refs/pull/<pull request number>/ . The head reference points at the tip of the branch that's being pull requested, ie the last commit on the branch. I'm not sure what the merge reference is though.

Answer 2

GitHub support would have a definitive answer, but I suspect it is based on the default 90 days period before automatic purge of the reflog .

gc.<pattern>.reflogexpire

git reflog expire removes reflog entries older than this time; defaults to 90 days .
With " <pattern> " (eg " refs/stash ") in the middle the setting applies only to the refs that match the <pattern> .

But... I you had a local copy with that branch still declared in it... nothing would prevent you to push said branch back to the gitHub repo ;)

Cupcake 's answer (upvoted) give that support answer: no limit , which means those two settings are both set to never :

• gc.reflogexpire
• gc.reflogexpireunreachable

That makes sense for a hosting repo service which doesn't modify those repos locally, and only store modifications pushed from external contributors.

---

Update Git 2.22 (Q2 2019, five years later): that last case (setting gc.reflogexpire and gc.reflogexpireunreachable to never ) is better handled.

See commit bf3d70f , commit 978f430 (28 Mar 2019), commit fe66776 , commit a65bf78 , commit cd8eb3a , commit e5cdbd5 (15 Mar 2019), and commit 8bf1444 (13 Mar 2019) by Ævar Arnfjörð Bjarmason ( avar ) .
^{(Merged by Junio C Hamano -- gitster -- in commit f3c19f8 , 25 Apr 2019)}

gc : handle & check gc.reflogExpire config

Don't redundantly run " git reflog expire --all " when gc.reflogExpire and gc.reflogExpireUnreachable are set to " never ", and die immediately if those configuration valuer are bad.

As an earlier "assert lack of early exit" change to the tests for " git reflog expire " shows, an early check of gc.reflogExpire{Unreachable,} isn't wanted in general for " git reflog expire ", but it makes sense for " gc " because:

1. Similarly to 8ab5aa4 (" parseopt : handle malformed --expire arguments more nicely", 2018-04-21, Git v2.18.0-rc0) we'll now die early if the config variables are set to invalid values.
   We run " pack-refs " before " reflog expire ", which can take a while, only to then die on an invalid gc.reflogExpire{Unreachable,} configuration.

2. Not invoking the command at all means it won't show up in track output, which makes what's going on more obvious when the two are set to " never ".

3. As a later change documents we lock the refs when looping over the refs to expire, even in cases where we end up doing nothing due to this config.

Answer 3

Note that some pull-request pages on GitHub will not show the Delete/Restore branch buttons, even though the references are safely stored as described by Cupcake .

This probably means the same branch was used again in a later pull request. Search the repo (in GitHub) for the branch name and check the latest pull request on that branch. You should find the UI to restore (or delete) the branch there.