Ответ 1
Когда вы используете git push origin :staleStuff
, он автоматически удаляет origin/staleStuff
, поэтому при запуске git remote prune origin
вы обрезали какую-либо ветвь, которая была удалена кем-то другим. Скорее всего, ваши сотрудники теперь должны запустить git prune
, чтобы избавиться от удаленных веток.
Итак, что именно делает git remote prune
? Основная идея: локальные ветки (не отслеживающие ветки) не затрагиваются командой git remote prune
и должны быть удалены вручную.
Теперь, реальный пример для лучшего понимания:
У вас есть удаленный репозиторий с двумя ветвями: master
и feature
. Предположим, что вы работаете в обеих ветвях, так что в результате у вас есть эти ссылки в вашем локальном репозитории (указаны полные имена ссылок, чтобы избежать путаницы):
-
refs/heads/master
(краткое названиеmaster
) -
refs/heads/feature
(краткое имяfeature
) -
refs/remotes/origin/master
(короткое имяorigin/master
) -
refs/remotes/origin/feature
(короткое имяorigin/feature
)
Теперь, типичный сценарий:
- Некоторые другие разработчики заканчивают работу над
feature
, объединяют ее вmaster
и удаляют ветвьfeature
из удаленного репозитория. - По умолчанию, когда вы выполняете
git fetch
(илиgit pull
), ссылки не удаляются из вашего локального репозитория, поэтому у вас все еще есть все 4 ссылки. - Вы решили их очистить и запустите
git remote prune origin
. - git обнаруживает, что ветвь
feature
больше не существует, поэтомуrefs/remotes/origin/feature
является устаревшей ветвью, которую нужно удалить. - Теперь у вас есть 3 ссылки, включая
refs/heads/feature
, потому чтоgit remote prune
не удаляет ссылкиrefs/heads/*
.
Можно идентифицировать локальные ветки, связанные с удаленными ветвями отслеживания, с помощью параметра конфигурации branch.<branch_name>.merge
. Этот параметр не требуется для работы (возможно, кроме git pull
), поэтому он может отсутствовать.
(обновляется с примером и полезной информацией из комментариев)