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

For how long can you restore/recover a deleted branch on GitHub?

提问by BlackVegetable

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

这不是关于如何在 Github 中恢复丢失的分支的问题，而是通过以下用户案例故事您需要多长时间恢复已删除的分支：

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.

在拉取请求（通常用作代码的地方）中，分支可以合并然后删除，所有这些都在 github GUI 中。如果您选择删除它，您可以选择一个粗体和带下划线的词来“恢复”分支。

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

我怀疑这个选项有时间限制，而且 github 不会无限期地保持它可用。

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

github 是否对您可以执行此操作的时间有时间限制？如果是，那么这个时间限制是多少？

回答by

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

我问了GitHub 支持，这是他们的回答（重点是我的）：

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.

我们为所有 Pull Request 使用单独的 ref 命名空间，我们将其用于各种事情，包括恢复分支。由于我们无限期地保留这些 [Pull Request] 引用，因此恢复分支没有时间限制。

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

您可以使用以下命令在遥控器中查看这些特殊引用：

$ git ls-remote | grep pull
From [email protected]:<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 headreference points at the tip of the branch that's being pull requested, i.e. the last commit on the branch. I'm not sure what the mergereference is though.

引用的命名空间位于refs/pull/<pull request number>/. head被拉请求的分支顶端的参考点，即分支上的最后一次提交。我不确定merge参考是什么。

回答by jimallman

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

请注意，GitHub 上的某些拉取请求页面不会显示删除/恢复分支按钮，即使引用已按照 Cupcake 的描述安全存储。

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

这可能意味着在稍后的拉取请求中再次使用了相同的分支。在存储库（在 GitHub 中）搜索分支名称并检查该分支上的最新拉取请求。您应该在那里找到用于恢复（或删除）分支的 UI。

回答by VonC

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.

GitHub的支持，将有一个明确的答案，但我怀疑它是基于默认的90天左右的自动清除之前的reflog。

gc.<pattern>.reflogexpire

git reflogexpire removes reflogentries older than this time; defaults to 90 days.
With "<pattern>" (e.g. "refs/stash") in the middle the setting applies only to the refs that match the <pattern>.

git reflogexpire 删除reflog早于此时间的条目；默认为 90 天。中间
带有“ <pattern>”（例如“ refs/stash”）的设置仅适用于与<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 ;)

但是...我有一个本地副本，其中仍然声明了该分支...没有什么可以阻止您将所述分支推回 gitHub 存储库；)

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

Cupcake的回答（已投票）给出了支持答案：no limit，这意味着这两个设置都设置为never：

• gc.reflogexpire
• gc.reflogexpireunreachable

• 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.reflogexpireand gc.reflogexpireunreachableto never) is better handled.

更新 Git 2.22（2019 年第二季度，五年后）：最后一种情况（设置gc.reflogexpire和gc.reflogexpireunreachableto never）得到了更好的处理。

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?re Bjarmason (avar).
^{(Merged by Junio C Hamano -- gitster--in commit f3c19f8, 25 Apr 2019)}

见提交bf3d70f，提交978f430（2019年3月28日），提交fe66776，提交a65bf78，提交cd8eb3a，提交e5cdbd5（2019年3月15日），并提交8bf1444通过（2019年3月13日）？VAR Arnfj？再Bjarmason（ ）avar。
^{（由Junio C gitsterHamano合并-- --在提交 f3c19f8 中，2019 年 4 月 25 日）}

gc: handle & check gc.reflogExpireconfig

Don't redundantly run "git reflog expire --all" when gc.reflogExpireand gc.reflogExpireUnreachableare 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 --expirearguments 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.

gc：处理和检查gc.reflogExpire配置

和设置为“ git reflog expire --all”时不要重复运行“ ” ，如果那些配置评估器不好，则立即死亡。gc.reflogExpiregc.reflogExpireUnreachablenever

正如较早对“ git reflog expire”测试的“断言缺乏提前退出”更改所示，gc.reflogExpire{Unreachable,}一般不希望对“ git reflog expire”进行早期检查，但对“ ”来说是有意义的，gc因为：

1. 与8ab5aa4（“ parseopt：--expire更好地处理格式错误的参数”，2018 年 4 月 21 日，Git v2.18.0-rc0）类似，如果配置变量设置为无效值，我们现在会提前死亡。
   我们在“ pack-refs”之前运行“ ” reflog expire，这可能需要一段时间，然后会因无效gc.reflogExpire{Unreachable,}配置而死亡。

2. 根本不调用命令意味着它不会出现在轨道输出中，这使得当两者设置为“ never”时发生的事情更加明显。

3. 作为稍后的更改文档，我们在循环引用到期时锁定引用，即使在由于此配置我们最终什么都不做的情况下。