Как восстановить удаленную ветку git
Перейти к содержимому

Как восстановить удаленную ветку git

  • автор:

Можно ли восстановить удалённую ветку в гите, если я уже создал ветку с таким же именем?

если ничего не коммитилось и не «индексировалось», то по сути Ваша ветка это просто синоним какого то коммита в мастере. А значит, ничего не восстановить.

3 июн 2021 в 10:30

Если коммитов не делали, то что хотите восстановить? Изменения в локальной копии, которые вы отменили?

3 июн 2021 в 10:33
Я хочу восстановить то что было, на момент git checkout master
3 июн 2021 в 10:43

Если вы коммитили, то можно попробовать найти нужный коммит где-нибудь на просторах git reflog. Если не коммитили — ну, тогда гит здесь уже ни при чём, соболезнуем

3 июн 2021 в 10:49
3 июн 2021 в 11:07

1 ответ 1

Сортировка: Сброс на вариант по умолчанию

Ветку восстановить можно, только в этой ситуации, к сожалению, восстановить изменения это не поможет.

Ветка это указатель на комит. Когда создаете ветку, то она изначально указывает на тот комит, от которого ее породили.

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

Отслеживать
ответ дан 3 июн 2021 в 11:44
Roman-Stop RU aggression in UA Roman-Stop RU aggression in UA
23.3k 1 1 золотой знак 18 18 серебряных знаков 29 29 бронзовых знаков
Спасибо, уже понял. ����
3 июн 2021 в 13:32

@AndrewKachalin поэтому коммитить надо всё. Любую глупость (можно в отдельные ветки). Удалить потом ненужные ветки и коммиты проще, чем восстанавливать несохранённый код.

SOS!! Как восстановить ветки в локальном репозитории?

Помогите пожалуйста, я новичок! Случайно снес в папке локального репозитория git файл, и у меня пропали все ветки в локальном репозитории, на удаленном репозитории все ветки есть, а на локальном пусто, пытался решить git inint и git remote add origin https/… с последующим git pull, не помогло. Можно ли восстановить ветки на локальном репозитории, если да то как(перенести например с удаленного)? Если нельзя, то как теперь правильно поступить?

3.5 Ветвление в Git — Удалённые ветки

Удалённые ссылки — это ссылки (указатели) в ваших удалённых репозиториях, включая ветки, теги и так далее. Полный список удалённых ссылок можно получить с помощью команды git ls-remote или команды git remote show для получения удалённых веток и дополнительной информации. Тем не менее, более распространённым способом является использование веток слежения.

Ветки слежения — это ссылки на определённое состояние удалённых веток. Это локальные ветки, которые нельзя перемещать; Git перемещает их автоматически при любой коммуникации с удалённым репозиторием, чтобы гарантировать точное соответствие с ним. Представляйте их как закладки для напоминания о том, где ветки в удалённых репозиториях находились во время последнего подключения к ним.

Имена веток слежения имеют вид / . Например, если вы хотите посмотреть, как выглядела ветка master на сервере origin во время последнего соединения с ним, используйте ветку origin/master . Если вы с коллегой работали над одной задачей и он отправил на сервер ветку iss53 , при том что у вас может быть своя локальная ветка iss53 , удалённая ветка будет представлена веткой слежения с именем origin/iss53 .

Возможно, всё это сбивает с толку, поэтому давайте рассмотрим на примере. Скажем, у вас в сети есть свой Git-сервер с адресом git.ourcompany.com . Если вы с него что-то клонируете, команда clone автоматически назовёт его origin , заберёт оттуда все данные, создаст указатель на то, на что там указывает ветка master , и назовёт его локально origin/master . Git также создаст вам локальную ветку master , которая будет начинаться там же, где и ветка master в origin , так что вам будет с чего начать.

Примечание
«origin» — это не специальное название

Подобно названию ветки «master», «origin» не имеет какого-либо специального значения в Git. В то время как «master» — это название по умолчанию для ветки при выполнении git init только потому, что часто используется, «origin» — это название по умолчанию для удалённого сервера, когда вы запускаете git clone . Если вы выполните git clone -o booyah , то по умолчанию ветка слежения будет иметь вид booyah/master .

Серверный и локальный репозитории после клонирования

Рисунок 30. Серверный и локальный репозитории после клонирования

Если вы сделаете что-то в своей локальной ветке master , а тем временем кто-то отправит изменения на сервер git.ourcompany.com и обновит там ветку master , то ваши истории продолжатся по-разному. Пока вы не свяжетесь с сервером origin ваш указатель origin/master останется на месте.

Локальная и удалённая работа может расходиться

Рисунок 31. Локальная и удалённая работа может расходиться

Для синхронизации ваших изменений с удалённым сервером выполните команду git fetch (в нашем случае git fetch origin ). Эта команда определяет какому серверу соответствует «origin» (в нашем случае это git.ourcompany.com ), извлекает оттуда данные, которых у вас ещё нет, и обновляет локальную базу данных, сдвигая указатель origin/master на новую позицию.

`git fetch` обновляет ветки слежения

Рисунок 32. git fetch обновляет ветки слежения

Чтобы продемонстрировать, как будут выглядеть удалённые ветки в ситуации с несколькими удалёнными серверами, предположим, что у вас есть ещё один внутренний Git-сервер, который используется для разработки только одной из ваших команд разработчиков. Этот сервер находится на git.team1.ourcompany.com . Вы можете добавить его в качестве новой удалённой ссылки для текущего проекта с помощью команды git remote add , как было описано в главе Основы Git. Назовите этот удалённый сервер teamone — это имя будет сокращением вместо полного URL.

Добавление ещё одного сервера в качестве удалённой ветки

Рисунок 33. Добавление ещё одного сервера в качестве удалённой ветки

Теперь вы можете выполнить команду git fetch teamone для получения всех изменений с сервера teamone , которых у вас нет локально. Так как в данный момент на этом сервере есть только те данные, что содержит сервер origin , Git ничего не получит, но создаст ветку слежения с именем teamone/master , которая будет указывать на тот же коммит, что и ветка master на сервере teamone .

Ветка слежения `teamone/master`

Рисунок 34. Ветка слежения teamone/master

Отправка изменений

Когда вы хотите поделиться веткой, вам необходимо отправить её на удалённый сервер, где у вас есть права на запись. Ваши локальные ветки автоматически не синхронизируются с удалёнными при отправке — вам нужно явно указать те ветки, которые вы хотите отправить. Таким образом, вы можете использовать свои личные ветки для работы, которую не хотите показывать, а отправлять только те тематические ветки, над которыми вы хотите работать с кем-то совместно.

Если у вас есть ветка serverfix , над которой вы хотите работать с кем-то ещё, вы можете отправить её точно так же, как вы отправляли вашу первую ветку. Выполните команду git push :

$ git push origin serverfix Counting objects: 24, done. Delta compression using up to 8 threads. Compressing objects: 100% (15/15), done. Writing objects: 100% (24/24), 1.91 KiB | 0 bytes/s, done. Total 24 (delta 2), reused 0 (delta 0) To https://github.com/schacon/simplegit * [new branch] serverfix -> serverfix

Это в некотором роде сокращение. Git автоматически разворачивает имя ветки serverfix до refs/heads/serverfix:refs/heads/serverfix , что означает «возьми мою локальную ветку serverfix и обнови ей удалённую ветку serverfix ». Мы подробно рассмотрим часть с refs/heads/ в главе Git изнутри, но обычно её можно пропустить. Вы также можете выполнить git push origin serverfix:serverfix — произойдёт то же самое — здесь говорится «возьми мою ветку serverfix и сделай её удалённой веткой serverfix ». Можно использовать этот формат для отправки локальной ветки в удалённую ветку с другим именем. Если вы не хотите, чтобы на удалённом сервере ветка называлась serverfix , то вместо предыдущей команды выполните git push origin serverfix:awesomebranch , которая отправит локальную ветку serverfix в ветку awesomebranch удалённого репозитория.

Примечание
Не вводите каждый раз свой пароль

Если вы используете HTTPS URL для отправки изменений, Git-сервер будет спрашивать имя пользователя и пароль для аутентификации. По умолчанию вам будет предложено ввести эти данные в терминале, чтобы сервер мог определить разрешена ли вам отправка изменений.

Если вы не хотите вводить свои данные каждый раз при отправке изменений, вы можете настроить «credential cache». Проще всего держать их в памяти несколько минут, это легко настроить с помощью команды git config —global credential.helper cache .

Для получения более подробной информации о различных вариантах кэша учётных данных обратитесь к разделу Хранилище учётных данных.

В следующий раз, когда один из ваших соавторов будет получать обновления с сервера, он получит ссылку на то, на что указывает serverfix на сервере, как удалённую ветку origin/serverfix :

$ git fetch origin remote: Counting objects: 7, done. remote: Compressing objects: 100% (2/2), done. remote: Total 3 (delta 0), reused 3 (delta 0) Unpacking objects: 100% (3/3), done. From https://github.com/schacon/simplegit * [new branch] serverfix -> origin/serverfix

Необходимо отметить, что при получении данных создаются ветки слежения, вы не получаете автоматически для них локальных редактируемых копий. Другими словами, в нашем случае вы не получите новую ветку serverfix — только указатель origin/serverfix , который вы не можете изменять.

Чтобы слить эти наработки в свою текущую рабочую ветку, выполните git merge origin/serverfix . Если вам нужна локальная ветка serverfix , в которой вы сможете работать, то вы можете создать её на основе ветки слежения:

$ git checkout -b serverfix origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

Это даст вам локальную ветку, в которой можно работать и которая будет начинаться там же, где и origin/serverfix .

Отслеживание веток

Получение локальной ветки из удалённой ветки автоматически создаёт то, что называется «веткой слежения» (а ветка, за которой следит локальная называется «upstream branch»). Ветки слежения — это локальные ветки, которые напрямую связаны с удалённой веткой. Если, находясь на ветке слежения, выполнить git pull , то Git уже будет знать с какого сервера получать данные и какую ветку использовать для слияния.

При клонировании репозитория, как правило, автоматически создаётся ветка master , которая следит за origin/master . Однако, при желании вы можете настроить отслеживание и других веток — следить за ветками на других серверах или отключить слежение за веткой master . Вы только что видели простейший пример, что сделать это можно с помощью команды git checkout -b / . Это часто используемая команда, поэтому Git предоставляет сокращённую форму записи в виде флага —track :

$ git checkout --track origin/serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

В действительности, это настолько распространённая команда, что существует сокращение для этого сокращения. Если вы пытаетесь извлечь ветку, которая не существует, но существует только одна удалённая ветка с точно таким же именем, то Git автоматически создаст ветку слежения:

$ git checkout serverfix Branch serverfix set up to track remote branch serverfix from origin. Switched to a new branch 'serverfix'

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

$ git checkout -b sf origin/serverfix Branch sf set up to track remote branch serverfix from origin. Switched to a new branch 'sf'

Теперь ваша локальная ветка sf будет автоматически получать изменения из origin/serverfix .

Если у вас уже есть локальная ветка и вы хотите настроить её на слежение за удалённой веткой, которую вы только что получили, или хотите изменить используемую upstream-ветку, то воспользуйтесь параметрами -u или —set-upstream-to для команды git branch , чтобы явно установить новое значение.

$ git branch -u origin/serverfix Branch serverfix set up to track remote branch serverfix from origin.

Примечание
Сокращение Upstream

Если у вас настроена отслеживаемая ветка, вы можете ссылаться на неё с помощью сокращений @ или @ . Итак, если вы находитесь на ветке master и она следит за origin/master , при желании вы можете использовать git merge @ вместо git merge origin/master .

Если вы хотите посмотреть как у вас настроены ветки слежения, воспользуйтесь опцией -vv для команды git branch . Это выведет список локальных веток и дополнительную информацию о том, какая из веток отслеживается, отстаёт, опережает или всё сразу относительно отслеживаемой.

$ git branch -vv iss53 7e424c3 [origin/iss53: ahead 2] Add forgotten brackets master 1ae2a45 [origin/master] Deploy index fix * serverfix f8674d9 [teamone/server-fix-good: ahead 3, behind 1] This should do it testing 5ea463a Try something new

Итак, здесь мы видим, что наша ветка iss53 следит за origin/iss53 и «опережает» её на два изменения — это значит, что у нас есть два локальных коммита, которые не отправлены на сервер. Мы также видим, что наша ветка master отслеживает ветку origin/master и находится в актуальном состоянии. Далее мы можем видеть, что локальная ветка serverfix следит за веткой server-fix-good на сервере teamone , опережает её на три коммита и отстает на один — это значит, что на сервере есть один коммит, который мы ещё не слили, и три локальных коммита, которые ещё не отправлены на сервер. В конце мы видим, что наша ветка testing не отслеживает удалённую ветку.

Важно отметить, что эти цифры описывают состояние на момент последнего получения данных с каждого из серверов. Эта команда не обращается к серверам, а лишь говорит вам о том, какая информация с этих серверов сохранена в локальном кэше. Если вы хотите иметь актуальную информацию об этих числах, вам необходимо получить данные со всех ваших удалённых серверов перед запуском команды. Сделать это можно вот так:

$ git fetch --all; git branch -vv

Получение изменений

Команда git fetch получает с сервера все изменения, которых у вас ещё нет, но не будет изменять состояние вашей рабочей копии. Эта команда просто получает данные и позволяет вам самостоятельно сделать слияние. Тем не менее, существует команда git pull , которая в большинстве случаев является командой git fetch , за которой непосредственно следует команда git merge . Если у вас настроена ветка слежения как показано в предыдущем разделе, или она явно установлена, или она была создана автоматически командами clone или checkout , git pull определит сервер и ветку, за которыми следит ваша текущая ветка, получит данные с этого сервера и затем попытается слить удалённую ветку.

Обычно, лучше явно использовать команды fetch и merge , поскольку магия git pull может часто сбивать с толку.

Удаление веток на удалённом сервере

Скажем, вы и ваши соавторы закончили с нововведением и слили его в ветку master на удалённом сервере (или в какую-то другую ветку, где хранится стабильный код). Вы можете удалить ветку на удалённом сервере используя параметр —delete для команды git push . Для удаления ветки serverfix на сервере, выполните следующую команду:

$ git push origin --delete serverfix To https://github.com/schacon/simplegit - [deleted] serverfix

Всё, что делает эта строка — удаляет указатель на сервере. Как правило, Git сервер хранит данные пока не запустится сборщик мусора, поэтому если ветка была удалена случайно, чаще всего её легко восстановить.

Можно ли восстановить ветку после ее удаления в Git?

Если я запустил git branch -d XYZ , есть ли способ восстановить ветвь? Есть ли способ вернуться, как будто я не запускал команду удаления ветки?

prosseek 04 сен. 2010, в 03:59
Поделиться

Замечательное замечание по поводу принятого ответа — это то, что он работает, даже если ветка была удалена в источнике! Я только что восстановил несколько веток, которых у меня больше не было локально после того, как они были случайно удалены в источнике.

theblang 21 май 2018, в 21:35
Отличный пост: medium.com/@zaran.56/…
Imran 27 июнь 2018, в 08:45
Поделиться:

17 ответов

Лучший ответ

Да, вы должны быть в состоянии сделать git reflog и найти SHA1 для коммита в конце вашей удаленной ветки, а затем просто git checkout [sha] . И как только вы получите этот коммит, вы можете просто сделать git checkout -b [branchname] чтобы воссоздать ветку оттуда.

Благодарим @Cascabel за эту сокращенную/однострочную версию.

Вы можете сделать это за один шаг:

git checkout -b
tfe 04 сен. 2010, в 04:05
Поделиться
Вы можете сделать это за один шаг: git checkout -b .
Cascabel 04 сен. 2010, в 14:19

Подсказка — если вы только что удалили ветку, вы увидите что-то вроде этого в своем терминале — «Удаленная ветка (была )». И тогда это очень просто — просто используйте это . Например, как упомянуто выше — git checkout -b

Snowcrash 29 май 2014, в 14:37
да, просто прокрутите вверх в своем терминале (если вы не сделали CMD+K )
neaumusic 20 май 2015, в 20:50
Используйте git reflog —no-abbrev чтобы увидеть полный , сокращенный по умолчанию.
jkulak 11 нояб. 2015, в 11:28
Спасибо, спасибо и спасибо!
CodeFinity 19 янв. 2016, в 23:54

В моем случае ветвь была удалена другим коллегой, поэтому фиксация также исчезла. К счастью, у этого коллеги все еще была ветка локально, и он мог восстановить ветку, просто выполнив git checkout && git push origin

Claudiu 29 янв. 2016, в 16:10
Спасибо, что сэкономили мне много времени .. (Y)
Sajith Vijesekara 09 июнь 2016, в 05:20
Боже мой, ты спас мой день
wayofthefuture 11 июнь 2016, в 17:57
Отлично, это спасло меня. 🙂
vivek kumar 30 авг. 2016, в 06:16
Потрясающие! Что-то новое я узнал сегодня, и это спасло меня от сложной ситуации.
Rutwick Gangurde 27 дек. 2016, в 11:57

Для любого другого, как я, у которого были проблемы с поиском ша удаленной ветки: я смог сделать git checkout remotes/origin/deleted_branch .

Jeff Irwin 07 июнь 2017, в 13:04
Спас мой бекон. Спасибо!
Dan Barron 27 июль 2017, в 19:19
Вы буквальный спасатель
GordonM 17 авг. 2017, в 14:12

Это как когда я учился в колледже, когда мой Zip-диск Iomega с моими проектами был на грани смерти. На этот раз это было из-за толстого пальца с моей стороны, но в отличие от колледжа меня спасли! ДОЛЖЕН НАУЧИТЬСЯ git push -u

Ray 24 авг. 2017, в 11:47
Большое спасибо. спас мой день
Bhautik Ziniya 08 нояб. 2017, в 14:25
Учитесь на примере: medium.com/@zaran.56/…
Imran 02 июнь 2018, в 05:49

Для тех, кто сделал удаление из SourceTree, а не из командной строки, вы можете узнать свой SHA1, перейдя в View -> Show History History. Найдите команду «Удаление ветви» и найдите сообщение «Удаленная ветвь <имя-ветви>(было )».

Nobosi 26 сен. 2018, в 19:17
это круто!! ты спасатель
Aayushi 26 окт. 2018, в 07:01
Вау, ребята! Ты спас мне жизнь: D
Victor 18 нояб. 2018, в 03:52
спасибо за спасение моей жизни чувак
Felipe Castillo 24 янв. 2019, в 13:58
Легендарный ответ!
Ashish 01 фев. 2019, в 14:32
Ты спас мне жизнь .
Carlos Alvarez 12 март 2019, в 00:11
Показать ещё 20 комментариев

В большинстве случаев недостижимые коммиты находятся в рефлоге. Итак, , первое, что нужно попробовать, это посмотреть на reflog, используя команду git reflog (которая отображает reflog для HEAD ).

Возможно, что-то легче, если коммит был частью конкретной ветки, которая все еще существует, — это использовать команду git reflog name-of-my-branch . Он работает также с удаленным, например, если вы принудительно нажимаете.

Если ваши коммиты не находятся в вашем рефлоге (возможно, потому что они были удалены сторонним инструментом, которые не записывают в reflog), я успешно восстановил ветвь, переведя мою ветку в sha of фиксация найдена с использованием такой команды (она создает файл со всеми оборванными коммитами):

git fsck --full --no-reflogs --unreachable --lost-found | grep commit | cut -d\ -f3 | xargs -n 1 git log -n 1 --pretty=oneline > .git/lost-found.txt 

Если вы должны использовать его более одного раза (или хотите его где-то сохранить), вы также можете создать псевдоним с этой командой.

git config --global alias.rescue '!git fsck --full --no-reflogs --unreachable --lost-found | grep commit | cut -d\ -f3 | xargs -n 1 git log -n 1 --pretty=oneline > .git/lost-found.txt' 

и используйте его с git rescue

Чтобы исследовать найденные коммиты, вы можете отображать каждую фиксацию, используя некоторые команды, чтобы просмотреть их.

Чтобы отобразить метаданные передачи (автор, дата создания и сообщение фиксации):

git cat-file -p 48540dfa438ad8e442b18e57a5a255c0ecad0560 

Чтобы увидеть также различия:

git log -p 48540dfa438ad8e442b18e57a5a255c0ecad0560 

После того, как вы нашли свою фиксацию, затем создайте ветку на этом коммите с помощью:

git branch commit_rescued 48540dfa438ad8e442b18e57a5a255c0ecad0560 

Philippe 10 март 2014, в 15:29
Поделиться

Огромная помощь. У меня был потерянный коммит, которого никогда не было в моем локальном репо. Первая ваша команда помогла мне найти ее на сервере. +1

Sean Adkinson 30 июнь 2017, в 19:00
спас мою жизнь чувак. очень полезный комментарий.
asaenko 06 окт. 2017, в 20:51
@asaenko, так что, возможно, тебе стоит проголосовать .
Philippe 13 окт. 2017, в 10:27
этот псевдоним спасения — находка . Большое спасибо за помощь!
72A12F4E 16 янв. 2018, в 18:28
Узнайте на примере medium.com/@zaran.56/…
Imran 02 июнь 2018, в 05:50
Показать ещё 3 комментария

Если вы хотите использовать графический интерфейс, вы можете выполнить всю операцию с помощью gitk.

gitk --reflog 

Это позволит вам увидеть историю фиксации ветки, как если бы ветка не была удалена. Теперь просто щелкните правой кнопкой мыши самую последнюю фиксацию на ветку и выберите пункт меню Create new branch .

nobar 02 июнь 2015, в 15:29
Поделиться
Большое спасибо. Эта команда помогает мне.
sg552 09 авг. 2016, в 04:15
Узнайте на примере medium.com/@zaran.56/…
Imran 02 июнь 2018, в 05:50

Самое популярное решение действительно больше, чем было запрошено:

git checkout git checkout -b

git checkout -b

переместит вас в новую ветку вместе со всеми недавними изменениями, которые вы, возможно, забыли совершить. Это может быть не ваше намерение, особенно когда в «режиме паники» после потери ветки.

A более чистое (и более простое) решение кажется однострочным (после того, как вы нашли с git reflog ):

git branch

Теперь ни ваша текущая ветвь, ни неизменные изменения не затронуты. Вместо этого только новая ветвь будет создана до .

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

Наконец, вы можете переименовать успешно восстановленную ветку в то, что она была названа, или что-то еще:

git branch -m

Излишне говорить, что ключом к успеху было найти правильную фиксацию , поэтому назовите свои коммиты разумно:)

Dmitri Zaitsev 08 апр. 2015, в 16:39
Поделиться

Добавление в tfe ответ: есть также git-resurrect.sh script в области contrib/ в Git источники (в хранилище git.git), которые могут вам помочь.

git-resurrect пытается найти следы кончика ответвления называется и пытается его воскресить. В настоящее время reflog поиск сообщений проверки, а с помощью -r — также слияние сообщений. С -m и -t , история всех refs сканируется для Merge into other / Merge into (соответственно) объектов фиксации, которые довольно медленный, но позволяет воскрешать тему других людей ветки.

Jakub Narębski 06 сен. 2010, в 20:52
Поделиться
Это на самом деле работает? Кто-нибудь проверял это?
Dmitri Zaitsev 28 апр. 2015, в 13:35

Теперь это работает для меня, хотя мне пришлось добавить / usr / lib / git-core / в мою PATH. Но это не выполнило чудо, на которое я надеялся 🙁

AmanicA 27 нояб. 2015, в 04:59

Если у вас нет reflog, например. потому что вы работаете в голом репозитории, в котором нет reflog, и коммит, который вы хотите восстановить, был создан недавно, другой вариант — найти недавно созданные объекты фиксации и просмотреть их.

Изнутри каталога .git/objects выполните:

find . -ctime -12h -type f | sed 's/[./]//g' | git cat-file --batch-check | grep commit 

Это находит все объекты (фиксации, файлы, теги и т.д.), созданные за последние 12 часов, и фильтрует их для отображения только коммитов. Проверка их — это быстрый процесс.

Я попробовал бы git -ressurect.sh script, упомянутый в ответ Jakub, хотя.

Robert Knight 13 май 2013, в 11:38
Поделиться

Хорошая альтернативная идея! Ваша команда выдает ошибку, хотя. Проблема в части «12h» (фактически «h»). Как только я удалил букву «h», все заработало. От man find : «-ctime n — статус файла был последний раз изменен n * 24 часа назад.» Таким образом, мы должны также изменить 12 на 0,5, чтобы иметь ожидаемое поведение последних 12 часов.

pagliuca 15 май 2013, в 12:23
Я использую OS X 10.8 здесь, поэтому флаги ‘find’ выше основаны на версии, которая поставляется.
Robert Knight 15 май 2013, в 13:13

Да, конечно, проблема с версиями! Вот почему я проголосовал за ваш ответ на первом месте! Я просто прокомментировал, чтобы люди понимали, что параметры могут быть разными.

pagliuca 15 май 2013, в 17:29
Показать ещё 1 комментарий

Я использовал следующие команды для поиска и извлечения удаленной ветки. Первые шаги из описания gcb.

$ git fsck --full --no-reflogs --unreachable --lost-found > lost $ cat lost | cut -d\ -f3 > commits $ cat commits | xargs -n 1 git log -n 1 --pretty=oneline 

Теперь найдите идентификатор git commit (GIT -SHA) на основе комментариев коммита и используйте его в приведенной ниже команде. Оформить покупку нового ветки под названием NEW-BRANCH с ранее найденным GIT -SHA:

$ git checkout -b NEW-BRANCH GIT-SHA 

Patrick Koorevaar 14 нояб. 2016, в 14:02
Поделиться

Для пользователей GitHub без Git:

Если вы хотите восстановить его с сайта GitHub, вы можете взломать их сайт;)

• Прежде всего, найдите эти SHA (commit hashes):

curl -i https://api.github.com/repos/PublicUser/PublicRepo/events 

. или для частных РЕПО:

curl -su YourUserName https://api.github.com/repos/YourUserName/YourProject/events 

. (будет запрошен пароль)

• Затем перейдите в GitHub и создайте новую временную ветку, которая будет удалена навсегда (предпочтительнее Chrome).

• Перейдите в ветки и удалите их.

На той же странице без перезагрузки откройте DevTools, Network panel. Теперь подготовьте.

• Нажмите «Восстановить». Вы заметите новую «линию». Щелкните его правой кнопкой мыши и выберите «Копировать как cURL» и сохраните этот текст в каком-либо редакторе.

• Добавить в конец скопированной строки кода, это: -H «Cookie BranchSHA» на ваш зонд SHA -H и имя BranchName с желаемым именем (BTW, это отличный взлом для переименования ветки из Интернета). Если вы не слишком медленны, вам нужно сделать этот запрос в любом случае. Например, просто скопируйте-вставьте в терминал.

PS

Я знаю, это не очень простое решение или правильное решение, но на всякий случай, если кто-то, без пароля root и виртуальной машины, во время hackathon должен будет сделать что-то странное. Это абсолютно реально, так что спасибо за то, что вы не торопитесь и удачи 🙂

ОБНОВИТЬ

Ахаха, я очень взволнован тем фактом, что кто-то из World Wide Web нашел мой ответ и, действительно, прочитав его, нашел его забавным или полезным и поддержал мой умопомрачительный, безумный и так ошибочный ответ: 🙂 Это замечательный мир вокруг, и мы, программисты и кодеры, являются одной из самых сумасшедших ее частей

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *