2013-02-24 3 views
1

Здесь сценарий, в первую очередь в главном дереве есть две папкиКак восстановить конкретную GIT ветвь

├── foo1 
│   └── index.php 
└── foo2 
    └── index.php 

Затем я создаю ветку b1 и добавить в еще две папки.

├── foo1 
│   └── index.php 
├── foo2 
│   └── index.php 
├── foo3 
│   └── index.php 
└── foo4 
    └── index.php 

После этого я команда git add . и силы переключиться обратно освоить git co -f master без commit команды. В настоящее время дерево теперь отсутствовал папку foo3 и foo4, но по-прежнему остается ветвь b1

├── foo1 
│ └── index.php 
└── foo2 
    └── index.php 

Мой вопрос заключается в том, чтобы восстановить папку 3 и 4 из ветви b1? Я пробовал git co b1, но папка 3,4 все еще исчезает.

+2

Вы никогда ничего не совершали на ветке 'b1', поэтому он все же указывает на то же сообщение, что и' master'. Вот почему проверка этого не приведет к восстановлению этих файлов. – poke

+0

попробуйте 'git stash' на ветке' b1' перед тем, как вернуться к 'master' – hiteshradia

ответ

1

Используйте git fsck для поиска оборванных капель. Вот пример:

$ git fsck --lost-found 
Checking object directories: 100% (256/256), done. 
dangling blob 54578ea3b3fb8d790bc5e19e36b52e601ec5433a 
dangling blob f719efd430d52bcfc8566a43b2eb655688d38871 

Вы можете перечислить их непосредственно:

$ ls .git/lost-found/other/ 
54578ea3b3fb8d790bc5e19e36b52e601ec5433a 
f719efd430d52bcfc8566a43b2eb655688d38871 

, а затем восстановить их один за одним.

$ cat .git/lost-found/other/54578ea3b3fb8d790bc5e19e36b52e601ec5433a 
<contents of file> 
$ mv .git/lost-found/other/54578ea3b3fb8d790bc5e19e36b52e601ec5433a <my-file-one> 

Я думаю, вам нужно будет восстановить структуру каталогов.

+0

' git fsck --lost-found' не показывает никакого blob. Поскольку, когда я git co -f master' с силой флага, он завершает удаление файлов в ветви, как говорит jthill. –

+0

Нет ничего в .git/lost-found/other? – GoZoner

+0

Примечание: прежде чем я написал свой ответ, я воспроизвел ваши команды и увидел две капли (перечисленные в моем ответе) с двумя файлами, которые я сдул с помощью git checkout -f, как вы это делали. Итак, проверьте .git/lost-found. – GoZoner

1

Вы можете вернуть их, как говорит GoZoner, но когда вы сделали checkout -f, вы сказали git, чтобы сбить все, что попало на пути этой проверки - это все в индексе, и все, что было в рабочей книге, которое изменилось между индексированными состояния и новой ветви.

В частности, с git add вы пометили foo{3,4}/index.php в качестве отслеживаемых файлов; во время проверки, если файл отслеживается в текущем индексе и не отслеживается в новом индексе, тогда он присутствовал в отслеживаемом состоянии, а теперь нет, поэтому переход в соответствие с новым отслеживаемым состоянием обязательно означает удаление файла из рабочей строки.

Обычно git отказывается удалить незарегистрированный контент для отслеживаемых файлов с более или менее пояснительным сообщением, но вы указали --force. Не делай этого.

Смежные вопросы