Почему git тянет все новые ветки?

Ответ 1

В моем случае проблема была связана с двумя ветвями, имеющими одинаковое имя (одна заглавная, одна строчная). После удаления ветки "дубликаты" из удаленного источника я запустил следующее:

git fetch --prune origin

и сообщение [новая ветвь] перестает отображаться после каждого нажатия. Документацию по черносливу смотрите по ссылке.

Ответ 2

Я мог бы воспроизвести поведение, указав ветку, не указанную в .git/packed_refs, и переименовал ее файл в .git/refs/remotes/origin в тот же, но в другом случае. (в файловой системе NTFS). И он излечивается путем переименования.

Угадайте, можете ли вы переименовать в форму, соответствующую удалённому имени, это будет для вас проблемой.

Думая больше и используя первую форму после редактирования:

У вас должны быть две ветки с похожим именем, которые отличаются только в случае на пульте!

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

Ответ 3

Как вы можете видеть здесь:

* [new branch]      Branch1 -> origin/Branch1
* [new branch]      Branch2 -> origin/Branch2
* [new branch]      branch1 -> origin/branch1
* [new branch]      branch2 -> origin/branch2

У вас есть 4 ветки, и их пары имеют одно и то же имя с разными верхними/нижними регистрами. Это невозможно отразить в Windows, поскольку ветки хранятся в виде файлов, и вы не можете иметь два файла Branch1 и Branch1 в той же папке.

Чтобы исправить это, удалите один из них, запустив git push origin :Branch1 и то же самое для Branch2.

Ответ 4

Если возникла аналогичная проблема, проблема заключалась в том, что существующая локальная папка не соответствовала имени на удаленном сервере из-за различий, чувствительных к регистру. То, что сработало для меня, собиралось

.git/refs/remotes/origin

где вы можете найти имя папки поврежденного ветки и переименовать его в имя, предлагаемое в строке *[new branch] ИЛИ удалить его и pull снова, pull заново создаст папку в правильном случае файловой системы.

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

Ответ 5

Я также использую git для Windows (версия 2.20.0.windows.1), и у меня возникла та же проблема, но мне удалось решить ее с помощью других ответов в этой теме.

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

Существовали следующие ветки:

feature/branch-1
feature/branch-2

Затем была создана новая ветвь:

Feature/branch-3

Обратите внимание, что все ветки имеют уникальные имена; но случай отличается от слова feature.

После git pull я получил уведомление о новой ветке; который создал файл branch-3 для под .git\refs\remotes\origin\feature. Порядок создания веток здесь, вероятно, имеет значение; потому что .git\refs\remotes\origin\feature существовал до .git\refs\remotes\origin\Feature; мой путь был строчным Изменение порядка создания ветвей, вероятно, приведет к пути с прописной буквы Feature.

Каждый последующий git pull будет сообщать об этой новой ветке.

Проблема заключалась в том, что, хотя файл для ветки существовал; ветвь не была добавлена в .git\packed-refs. Исправление заключалось в том, чтобы вручную добавить строку для проблемной ветки с правильным регистром:

# pack-refs with: peeled fully-peeled sorted 
...
<hash> refs/remotes/origin/feature/branch-1
<hash> refs/remotes/origin/feature/branch-2
<hash> refs/remotes/origin/Feature/branch-3
...

Где <hash> был взят из файла .git\refs\remotes\origin\feature\branch-3.

Также; размышляя над первоначальным вопросом. Скажем так, у меня были следующие ветки:

feature/branch-1
feature/Branch-1

Windows записывает хэш для обеих ветвей в один путь .git\refs\remotes\origin\feature\branch-1 (или заглавную B в зависимости от порядка создания ветки). Я не знаю, к чему это приведет, если вы попытаетесь git checkout в обе ветки.

Держу пари, что в .git\packed-refs есть только одна запись для обеих ветвей. Возможно, добавление записей для обеих ветвей поможет избавиться от нового сообщения о ветке, о котором сообщал git pull, но, как упоминалось выше, git checkout feature/branch-1, за которым следует git checkout feature/Branch-1, может быть интересным.

Надеюсь, что это полезно для кого-то еще!

Ответ 6

Что сработало для меня просто:

rm .git/index
git reset