Git pull фактически не восстанавливает мои отсутствующие файлы с удаленных

Я работаю над филиалом. Я сделал и перебросил его в удаленный репозиторий. Теперь некоторые файлы на этой ветке отсутствуют. Надеюсь, они все еще доступны на удаленной ветке, поэтому я попытался сделать git pull:

git pull origin feature/my_branch

Однако git говорит, что все синхронизировано с удаленным:

 * branch            feature/my_branch -> FETCH_HEAD
Already up-to-date.

Как это может быть актуально? Я не могу найти свои отсутствующие файлы локально, и мой проект не скомпилировался из-за этих отсутствующих файлов. Опять же, я могу видеть эти файлы в истории фиксации удаленной ветки на битбакете.

Ответы

Ответ 1

git pull соответствует последовательности a git fetch, а затем git merge. Поэтому, если вы удаляете файлы из своего локального репозитория, выполнение git pull не будет восстанавливать их.

Чтобы восстановить их, вам необходимо проверить файлы из удаленного репозитория, используя:

git checkout <branch name> -- <path/to/file>

<branch name> может быть локальным или удаленным.

Пример: использование удаленного репозитория

  • Удаленное имя восходящего потока: происхождение
  • Удаленная ветка: функция /xpto
  • Локальная ветка: функция /xpto
  • Файл отсутствует в локальной ветке: example.js
  • Восстановить файл в локальной ветке из удаленной ветки: git checkout origin/feature/xpto -- example.js
  • Теперь у вас есть example.js на вашей локальной ветке

Пример 2: Откат фиксации

  • git log
  • Текущий хеш фиксации 7bb2154cf23b68feb0a0bbbd95446f2cd8bf3a44
  • Хотите откат к этому хешу фиксации dbc04c23b2c6f2dd7bc9b5ef4aef22611a57c3ad
    • git checkout dbc04c23b2c6f2dd7bc9b5ef4aef22611a57c3ad
  • Только хотите восстановить файл example.js из вышеприведенного хеша
    • git checkout dbc04c23b2c6f2dd7bc9b5ef4aef22611a57c3ad -- example.js

Ответ 2

Предполагая, что вы правильно описали проблему, методы @danielcsgomes должны работать нормально.

Вы можете узнать, какие файлы находятся в вашей текущей фиксации, но не в вашем рабочем каталоге, запустив git status. Например (используя -s, чтобы сохранить короткий вывод):

$ rm structy.py
$ git status -s
 D structy.py

Чтобы получить только один файл назад:

$ git checkout -- structy.py

и обратно.

Иногда просто проверяя какую-либо другую ветку или ревизию, потом возвращаюсь туда, где вы были, будет делать трюк. Например, последняя фиксация на master здесь заключалась в том, чтобы добавить mp.py, поэтому, если я это сделаю:

$ rm mp.py
$ git status -s
 D mp.py
$ git checkout HEAD^
Note: checking out 'HEAD^'.
[verbiage about detached HEAD etc, snipped]
$ git checkout master
Previous HEAD position was 171ce6f... ignore *.log files
Switched to branch 'master'
$ git status -s
$ head -1 mp.py
from multiprocessing import Process, Queue

Но это не всегда работает. Он работает для mp.py, потому что предыдущий rev (HEAD^) не имеет его, а текущий (master), поэтому перемещение вперед от HEAD^ до master восстанавливает файл. Файл structy.py существует довольно давно, поэтому, если я удалю его и проведу HEAD^ или какую-либо другую ветку или что-то еще, он останется удаленным из-work-dir. Так что что-то вроде git checkout -- structy.py - это более простой способ восстановить его, если вы не хотите пойти на Очень большой молот: git reset --hard.

Если вы уверены, что хотите отказаться от любых сделанных вами изменений, вы можете git reset --hard HEAD. Например, рассмотрим:

$ git rm mp.py
rm 'mp.py'
$ git status -s
D  mp.py

(кстати, обратите внимание, что "D" находится в другом положении: "git rm" ed, а не только "rm" ed, поэтому я говорю git, что если я сделаю commit, mp.py следует удалить в новом коммите, это не просто случайность, которую я удалил). Тогда я решаю, нет, это неправильно, я хочу, чтобы все вернулось к тому, как это было в HEAD:

$ git reset --hard HEAD
HEAD is now at 523bacb add multiprocessing example
$ git status -s
$

Итак, используйте reset --hard, если вы уверены.