Обычно я не отвечаю на вопрос, в котором уже есть 16 ответов, но все остальные ответы неверны, а правильный ответ очень прост. Вопрос говорит: «Есть ли простой способ удалить все ветви отслеживания, удаленный эквивалент которых больше не существует?»
Если «простой» означает удаление их всех за один раз, не хрупкое, не опасное и не зависящее от инструментов, которые есть не у всех читателей, то правильный ответ: нет.
Некоторые ответы просты, но они не делают то, что просили. Другие делают то, что просили, но они не просты: все полагаются на синтаксический анализ выходных данных Git с помощью команд манипулирования текстом или языков сценариев, которые могут отсутствовать в каждой системе. Кроме того, в большинстве предложений используются фарфоровые команды, выходные данные которых не предназначены для анализа сценарием («фарфор» относится к командам, предназначенным для работы с человеком; сценарии должны использовать низкоуровневые команды «слесарного дела»).
Дальнейшее чтение:
Если вы хотите сделать это безопасно, для рассматриваемого варианта использования (ветви отслеживания сбора мусора, которые были удалены на сервере, но все еще существуют как локальные ветви) и только с командами Git высокого уровня, вы должны
git fetch --prune
(или git fetch -p
, который является псевдонимом, или git prune remote origin
который делает то же самое без извлечения, и, вероятно, это не то, что вы хотите большую часть времени).
- Обратите внимание на любые удаленные ветви, которые сообщаются как удаленные. Или, чтобы найти их позже,
git branch -v
(любая потерянная ветвь отслеживания будет помечена как «[ушел]»).
git branch -d [branch_name]
на каждой осиротевшей ветви отслеживания
(это то, что предлагают другие ответы).
Если вы хотите написать сценарий решения, то for-each-ref
это ваша отправная точка, как в ответе Марка Лонгаира здесь и на этот вопрос на другой вопрос , но я не могу найти способ использовать его без написания цикла сценария оболочки, без использования xargs или чего-то еще. ,
Исходное объяснение
Чтобы понять, что происходит, нужно понимать, что в ситуации отслеживания веток у вас есть не одна ветка, а три. (И помните, что «ветвь» означает просто указатель на коммит.)
Учитывая ветвь отслеживания feature/X
, удаленный репозиторий (сервер) будет иметь эту ветвь и вызывать ее feature/X
. Ваш локальный репозиторий имеет ветку, remotes/origin/feature/X
которая означает: «Это то, что удаленный сообщил мне, что его ветвь feature / X была, когда мы говорили в прошлый раз», и, наконец, локальный репозиторий имеет ветку, feature/X
которая указывает на ваш последний коммит, и настроен на «отслеживать» remotes/origin/feature/X
, что означает, что вы можете тянуть и толкать, чтобы держать их вровень.
В какой-то момент кто-то удалил feature/X
на пульте. С этого момента вы остаетесь с вашим локальным feature/X
(что, вероятно, вам больше не нужно, поскольку работа над функцией X предположительно завершена), и вашим, remotes/origin/feature/X
который, безусловно, бесполезен, потому что его единственная цель состояла в том, чтобы запомнить состояние ветки сервера ,
И Git позволит вам автоматически очистить избыточный remotes/origin/feature/X
- вот что git fetch --prune
делает - но по какой-то причине он не позволяет автоматически удалять свои собственные feature/X
... даже если ваш файл feature/X
все еще содержит потерянные данные отслеживания, поэтому он содержит информацию идентифицировать бывшие ветви отслеживания, которые были полностью объединены. (В конце концов, он может дать вам информацию, которая позволит вам выполнить операцию вручную.)
* master
в моей системе. У меня сработала следующая команда:git branch -d $(git branch --merged |tail -n +2)