Я б зазвичай не відповідав на запитання, на яке вже є 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
що означає: "Це те, що віддалений сказав мені, що його особливість / 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)