Как долго вы можете восстановить/восстановить удаленную ветку на GitHub?

Это не вопрос о том, как восстановить потерянные ветки в Github, а скорее, как долго вы должны восстановить удаленную ветвь с помощью следующей истории случая пользователя:

В запросе на перенос (часто используемом как место для просмотра кода) ветвь может быть объединена, а затем удалена, все в графическом интерфейсе github. Если вы решите удалить его, вам предоставляется опция с жирным и подчеркнутым словом, чтобы "восстановить" ветвь.

Я подозреваю, что этот параметр имеет ограничение по времени и что github не позволяет использовать его неограниченно.

Имеет ли github ограничение времени на то, как долго вы можете это сделать? Если это так, каков этот лимит времени?

Ответы

Ответ 1

Я спросил поддержку GitHub, это был их ответ (внимание мое):

Мы используем отдельное пространство имен ref для всех запросов Pull, которые мы используем для различных вещей, включая восстановление ветки. Поскольку мы сохраняем эти [Pull Request] refs неопределенно, нет ограничений по времени на восстановление ветки.

Вы можете увидеть эти специальные ссылки на своем пульте, используя следующее:

$ 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

Ссылки именуются под refs/pull/<pull request number>/. Контрольная точка head указывает на конец ответвления, который запрашивается, т.е. Последний фиксатор на ветке. Я не уверен, что ссылка merge.

Ответ 2

Поддержка GitHub будет иметь определенный ответ, но я подозреваю, что она основана на периоде по умолчанию 90 дней до автоматической очистки reflog.

gc.<pattern>.reflogexpire

git reflog expire удаляет записи reflog старше этого времени; по умолчанию до 90 дней.
С " <pattern> " (например, " refs/stash ") посередине настройка применяется только к ссылкам, которые соответствуют <pattern>.

Но... у вас была локальная копия с той ветвью, которая все еще объявлена в ней... ничто не помешает вам отодвинуть эту ветку обратно в репозиторий gitHub;)

Ответ Cupcake (upvoted) дает ответ поддержки: нет предела, что означает, что обе эти настройки установлены на never:

  • gc.reflogexpire
  • gc.reflogexpireunreachable

Это имеет смысл для службы репо хостинга, которая не изменяет эти репо локально, а сохраняет только те изменения, которые были выданы сторонними участниками.

Обновление Git 2.22 (Q2 2019, пять лет спустя): этот последний случай (когда gc.reflogexpire и gc.reflogexpireunreachable never gc.reflogexpireunreachable) лучше обрабатывается.

См. Коммит bf3d70f, коммит 978f430 (28 марта 2019 г.), коммит fe66776, коммит a65bf78, коммит cd8eb3a, коммит e5cdbd5 (15 мар 2019 г.) и коммит 8bf1444 (13 мар 2019 г.) от Арва Арнфьорда Бьярмасона (avar).
(Объединено Junio C Hamano - gitster - в коммите f3c19f8, 25 апреля 2019 г.)

gc: обрабатывать и проверять конфигурацию gc.reflogExpire

Не запускайте избыточно " git reflog expire --all ", когда gc.reflogExpire и gc.reflogExpireUnreachable установлены на " never ", и немедленно gc.reflogExpire gc.reflogExpireUnreachable, если эти оценщики конфигурации плохие.

Как показывает более раннее "утверждение об отсутствии досрочного выхода" в тестах " git reflog expire ", ранняя проверка gc.reflogExpire{Unreachable,} вообще не нужна для " git reflog expire ", но имеет смысл для " gc " потому что:

  1. Аналогично 8ab5aa4 (" parseopt: обрабатывать некорректные аргументы --expire более красиво", 2018-04-21, Git v2.18.0-rc0) мы теперь умрем раньше, если переменные конфигурации будут установлены в недопустимые значения.
    Мы запускаем " pack-refs " до " reflog expire ", что может занять некоторое время, только чтобы затем умереть в недопустимой gc.reflogExpire{Unreachable,}.

  2. Совсем не вызывать команду означает, что она не будет отображаться при выводе дорожки, что делает происходящее более очевидным, когда для обоих задано значение " never ".

  3. Как более поздние документы об изменениях, мы блокируем ссылки при циклическом истечении срока действия ссылок, даже в тех случаях, когда мы ничего не делаем из-за этой конфигурации.

Ответ 3

Обратите внимание, что на некоторых страницах запроса тяги на GitHub не будут отображаться кнопки кнопки удаления/восстановления, даже если ссылки безопасно сохранены как описано Cupcake.

Это, вероятно, означает, что одна и та же ветвь использовалась снова в более позднем запросе на растяжение. Найдите репо (в GitHub) для имени ветки и проверьте последний запрос на перенос в этой ветке. Вы должны найти пользовательский интерфейс для восстановления (или удаления) ветки там.