Когда вы используете git push origin :staleStuff
, он автоматически удаляет origin/staleStuff
, поэтому, когда вы запустили git remote prune origin
, вы удалили ветку, которая была удалена кем-то другим.Скорее всего, вашим коллегам теперь нужно запустить git prune
, чтобы избавиться от удаленных веток.
Так что же делает git remote prune
?Основная идея: локальные ветви (не отслеживающие ветви) не затрагиваются командой git remote prune
и должны быть удалены вручную.
Теперь пример из реальной жизни для лучшего понимания:
У вас естьудаленный репозиторий с 2 ветками: 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
), поэтому он может отсутствовать.
(обновлено с примером и полезной информацией из комментариев)