попробуйте это:

git submodule sync
git submodule update

эта ошибка может означать, что в подмодуле отсутствует фиксация. То есть репозиторий (A) имеет подмодуль (B). A хочет загрузить B так, чтобы он указывал на определенную фиксацию (в B). Если эта фиксация каким-то образом отсутствует, вы получите эту ошибку. Когда-то возможная причина: ссылка на фиксацию была вставлена в A, но фактическая фиксация не была выдвинута из B. Поэтому я бы начал там.

менее вероятно, есть проблема с разрешениями, и фиксацию нельзя вытащить (возможно, если вы использование Git + ssh).

убедитесь ,что пути подмодулей выглядят нормально.в git/config и .gitmodules.

последнее, что нужно попробовать-внутри каталога подмодулей: git reset HEAD --hard

возможные причины

Это может произойти, когда:

1. подмодуль(ы) были отредактированы на месте
2. подмодуль(Ы) зафиксирован, который обновляет хэш подмодуля, на который указывает
3. подмодуля(с) не толкнул.

например, что-то вроде этого получилось:

$ cd submodule
$ emacs my_source_file  # edit some file(s)
$ git commit -am "Making some changes but will forget to push!"

в этот момент должен быть подмодуль.

$ cd .. # back to parent repository
$ git commit -am "updates to parent repository"
$ git push origin master

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

решение

Informa человек, который изменил подмодуль, чтобы нажать, т. е.

$ cd submodule
$ git push

Это также может произойти, когда у вас есть подмодуль, указывающий на репозиторий, который был перезагружен, и данная фиксация "ушла". Хотя фиксация все еще может находиться в удаленном репозитории, она не находится в ветви. Если вы не можете создать новую ветку (например, не свой репозиторий), вам придется обновить супер-проект, чтобы указать на новую фиксацию. В качестве альтернативы вы можете переместить одну из своих копий подмодулей в другое место, а затем обновить суперпроект, чтобы указать на этот репозиторий вместо.

Я получил эту ошибку, когда я сделал:

$ git submodule update --init --depth 1

но фиксация в Родительском проекте указывала на более раннюю фиксацию.
Удаление папки подмодуля и запуск

$ git submodule update --init

не решил проблему. Я удалил РЕПО и попробовал снова без флага глубины, и это сработало.

этот ответ предназначен для пользователей SourceTree с ограниченным опытом работы с терминалом git.

откройте проблемный подмодуль из проекта Git (super-project).

Fetch и убедитесь, что "Fetch all tags" проверено.

Rebase потяните свой проект Git.

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

ваша история подмодулей безопасно сохраняется в подмодуле git в любом случае.

Итак, почему бы просто не удалить подмодуль и добавить его снова?

В противном случае, вы пытались вручную редактировать HEAD или refs/master/head в рамках подмодуля .git

просто чтобы быть уверенным, попробуйте обновить git бинарники.

GitHub для Windows имеет версию git version 1.8.4.msysgit.0 что в моем случае было проблемой. Обновление решило это.

в моем случае, ни один из ответов выше решить проблему даже thoungh они хорошие ответы. Поэтому я публикую свое решение (в моем случае есть два клиента git, клиент A и B):

1. перейти к dir подмодуля:

   cd sub
   

2. оформить заказ на master:

   git checkout master
   

3. rebase к коду фиксации, который оба клиента могут видеть

4. вернитесь к родительскому директору:

5. обязуются мастер!--5-->

6. изменение на другой клиент， do rebase снова.

7. наконец-то он работает нормально! Может быть, потерять пару коммитов, но это работает.

8. FYI, не пытайтесь удалить свой подмодуль, он останется .git/modules там и не может перечитывать этот подмодуль снова, если только реактивный локальный.

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

шаги, за которыми я следовал, чтобы удалить подмодуль, вдохновленный https://gist.github.com/kyleturner/1563153:

1. запустить git rm --cached
2. удалить соответствующие строки из .файл gitmodules.
3. удалить соответствующий раздел .git / config.
4. Удалить сейчас неотслеживаемые файлы субмодуль.
5. удалить каталог .git / modules/

опять же, это может быть полезно, если все, что вы хотите, это снова указать на голову подмодуля, и вы не усложнили ситуацию, сохранив локальную копию подмодуля неповрежденной. Он предполагает, что у вас есть подмодуль "право" в качестве собственного РЕПО, где бы ни было происхождение это так, и вы просто хотите вернуться к правильному включению его в качестве подмодуля.

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

просто наткнулся на эту проблему, и ни одно из этих решений работал для меня. То, что оказалось решением для моей проблемы, на самом деле намного проще: обновить Git. Мой был 1.7.1, и после того, как я обновил ее до 2.16.1 (последний), проблема ушла без следа! Думаю, я оставлю его здесь, Надеюсь, это кому-то поможет.