Когда вы используете 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
), поэтому он может отсутствовать.
(обновлено примером и полезной информацией из комментариев)
git remote show origin
и поискать любые ветки, отмеченныеstale