Мне нужно восстановить две ветки Git, которые я каким-то образом удалил во время push.
Эти две ветки были созданы в другой системе и затем помещены в мой «общий» (github) репозиторий.
В моей системе я (по-видимому) получил ветки во время выборки:
~/myfolder> git fetch
remote: Counting objects: 105, done.
remote: Compressing objects: 100% (58/58), done.
remote: Total 62 (delta 29), reused 0 (delta 0)
Unpacking objects: 100% (62/62), done.
From github.com:mygiturl
* [new branch] contact_page -> origin/contact_page
731d1bb..e8b68cc homepage -> origin/homepage
* [new branch] new_pictures -> origin/new_pictures
Сразу после этого я отправил свои локальные изменения в центральное репо. По какой-то причине эти ветки были удалены как из моей локальной системы, так и из центрального репо:
~/myfolder> git push
Counting objects: 71, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (43/43), done.
Writing objects: 100% (49/49), 4.99 KiB, done.
Total 49 (delta 33), reused 0 (delta 0)
To git@github.com:mygiturl.git
- [deleted] contact_page
+ e8b68cc...731d1bb homepage -> homepage (forced update)
bb7e9f2..e0d061c master -> master
- [deleted] new_pictures
e38ac2e..bb7e9f2 origin/HEAD -> origin/HEAD
731d1bb..e8b68cc origin/homepage -> origin/homepage
e38ac2e..bb7e9f2 origin/master -> origin/master
* [new branch] origin/contact_page -> origin/contact_page
* [new branch] origin/new_pictures -> origin/new_pictures
Снять ветви с машины, где они родились, не так уж и легко, поэтому я хотел бы попытаться восстановить их у своего местного жителя, если это возможно.
Вся информация о git "undo", которую я нашел в Google, связана с восстановлением потерянных коммитов. Я не думаю, что здесь это применимо, поскольку у меня нет идентификаторов фиксации для этих веток.
Я хотел бы знать, как мне их вернуть. Я также хотел бы знать, как они были удалены в первую очередь и как я могу избежать этого в будущем.
РЕДАКТИРОВАТЬ: по запросу, вот моя конфигурация репо
user.name=Craig Walker
user.email=github@softcraft.ca
alias.unadd=reset HEAD
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
remote.origin.url=git@github.com:MyGitURL.git
remote.origin.mirror=true
branch.master.remote=origin
branch.master.merge=refs/heads/master
alias.undo=reset --hard
alias.test=push -f ci HEAD:master
alias.st=status
alias.ci=commit
alias.br=branch
alias.co=checkout
alias.ch=checkout
alias.df=diff
alias.lg=log -p
alias.who=shortlog -s --
remote.ci.url=ContinuousIntegrationGitURL
remote.ci.fetch=+refs/heads/*:refs/remotes/ci/*
branch.photo.remote=origin
branch.photo.merge=refs/heads/photos
remote.foo.url=FooGitURL
remote.foo.fetch=+refs/heads/*:refs/remotes/cynthia/*
branch.homepage.remote=origin
branch.homepage.merge=refs/heads/homepage
git config -l
показывает локальный репозиторий?remote.origin.fetch
refspec не подходит для использования сremote.origin.mirror = true
. Вы хотите отразить или использовать репозиторий GitHub как обычный пульт? В моем ответе должны быть команды, которые вам нужны в любом случае.Ответы:
Я не специалист. Но ты можешь попробовать
чтобы найти фиксацию HEAD удаленной ветки и вернуть их.
источник
git branch <uid>
получил их обратно. Благодарность!remotes.origin.mirror
иremotes.origin.fetch
настройками, в противном случае вы обязаны снова столкнуться с проблемой (или неумышленно CLOBBER фиксаций толкнули от других сделок РЕПО).git fsck --full --no-reflogs | cut -d' ' -f3 | xargs -P8 git log --oneline | grep 'Release 2.60.0.157'
всего две команды спасают мою жизнь
1. Это список всех предыдущих заголовков
2. Это вернет HEAD для фиксации, которую вы удалили.
источник
git reflog
. Что еще я могу попробовать?Ваши удаленные ветки не потеряны, они были скопированы в origin / contact_page и origin / new_pictures «ветки удаленного отслеживания» с помощью полученной вами выборки (они также были вытеснены назад показанным вами push, но они были помещены в refs / remotes / origin / вместо refs / heads /). Проверьте
git log origin/contact_page
и ,git log origin/new_pictures
чтобы увидеть , если ваши локальные копии «до даты» с тем, что вы думаете , должны быть там. Если какие-либо новые коммиты были помещены в эти ветки (из какого-то другого репо) между извлечением и отправкой, которые вы показали, вы могли их «потерять» (но, вероятно, вы могли бы найти их в другом репо, которое совсем недавно подтолкнуло эти ветки) .Конфликт загрузки / извлечения
Похоже, вы выполняете выборку в обычном, «удаленном режиме» (удаленные ссылки / головы / хранятся локально в refs / remotes / origin /), но нажимаете в «зеркальном режиме» (локальные ссылки / помещаются в удаленные ссылки /) . Проверьте .git / конфигурацию и примирить
remote.origin.fetch
иremote.origin.push
настройку.Сделать резервную копию
Прежде чем пытаться внести какие-либо изменения, создайте простой tar или zip-архив или все локальное репо. Таким образом, если вам не нравится то, что происходит, вы можете попробовать еще раз из восстановленного репо.
Вариант A: перенастроить как зеркало
Если вы намерены использовать удаленное репо как зеркало локального, сделайте следующее:
Вы также можете в конечном итоге удалить все ваши refs / remotes / origin / refs, поскольку они бесполезны, если вы работаете в зеркальном режиме (ваши обычные ветки заменяют обычные ветки удаленного отслеживания).
Вариант B: перенастроить как обычный пульт
Но поскольку кажется, что вы используете это удаленное репо с несколькими «рабочими» репозиториями, вы, вероятно, не захотите использовать зеркальный режим. Вы можете попробовать это:
Затем, вы в конечном итоге хотите удалить фиктивные ссылки / пультов ДУ / происхождения рефов в удаленном репо:
git push origin :refs/remotes/origin/contact_page :refs/remotes/origin/new_pictures …
.Тестовый толчок
Попробуйте
git push --dry-run
посмотреть, что онgit push
будет делать, не внося никаких изменений в удаленное репо. Если вам не нравится то, что он собирается делать, восстановитесь из резервной копии (tar / zip) и попробуйте другой вариант.источник
.git
каталоге обязательно проверьте.git/packed_refs
в дополнение к.git/refs/
.git show-ref
выгружает всех ваших местных референсов (упакованных или «незакрепленных»). Вы по-прежнему сможете найти ссылки в репозитории, которые изначально отправили их в репозиторий GitHub (на другом компьютере? В чужом репо?). В противном случае, до тех пор , пока вы не сделали дс или чернослив, вы должны быть в состоянии кgit fsck
выходу , чтобы исследовать свисающие фиксаций и их прикрепить:git branch contact_page-recovered <SHA-1-of-dangling-commit>
.Если удаление произошло достаточно недавно (например, в момент О-НЕТ!), Вы все равно должны получить сообщение:
Deleted branch <branch name> (was abcdefghi).
вы все еще можете бегать:
git checkout abcdefghi
git checkout -b <some new branch name or the old one>
источник
узнать идентификатор Коиммита
git reflog
восстановить локальную ветку, которую вы удалили по ошибке
git branch need-recover-branch-name commitId
снова нажмите need-recovery-branch-name, если вы тоже удалили удаленную ветку
git push origin need-recover-branch-name
источник
git reflog
, вместо того, чтобы угадывать иgit show
.Данные все еще существуют в github, вы можете создать новую ветку из старых данных:
источник
Я думаю, что у вас несоответствующая конфигурация для «выборки» и «толчка», поэтому это привело к тому, что выборка / отправка по умолчанию не выполнялась должным образом. К счастью, вы получили ветки, которые впоследствии удалили, так что вы сможете воссоздать их с помощью явного нажатия.
источник
git push origin origin/contact_page:contact_page
получаю это:error: src refspec origin/contact_page does not match any
git rev-parse refs/remotes/origin/origin/contact_page
говорит? Из-за фальшивой конфигурации «зеркало» ветка my теперь упоминается здесь, в локальном репозитории.Если ваша организация использует JIRA или другую подобную систему, связанную с git, вы можете найти коммиты, перечисленные в самом билете, и щелкнуть ссылки на изменения кода. Github удаляет ветку, но коммиты по-прежнему доступны для выбора.
источник
Это может показаться слишком осторожным, но я часто заархивирую копию всего, над чем я работал, прежде чем вносить изменения в систему контроля версий. В проекте Gitlab, над которым я работаю, я недавно по ошибке удалил удаленную ветку, которую хотел сохранить после слияния запроса на слияние. Оказывается, все, что мне нужно было сделать, чтобы вернуть его с историей коммитов, - это снова нажать. Запрос на слияние все еще отслеживался Gitlab, поэтому справа от ветки по-прежнему отображается синяя метка «объединено». Я все еще заархивировал свою локальную папку на случай, если что-то случится.
источник