Удалить ветки.
Если никто не знает, кто они, и никто не претендует на них, вряд ли кто-то узнает. Подобно тому, как копить старые газеты «на всякий случай», они просто мешают что-то сделать. Отпусти ситуацию. Особенно, если они скорее отстают и могут быть PITA для обновления.
Удаление их очень быстро скажет вам, полагается ли что-нибудь или кто-либо на них. Для небольшого количества контролируемой боли вы разрешили большую неопределенность. И люди научатся не оставлять важные вещи, просто валяясь в беспорядке.
В Git ветки эфемерны, и их достаточно легко восстановить различными способами. Есть простые вещи, которые вы можете сделать, чтобы сделать этот процесс более простым и надежным. Это главным образом для того, чтобы ваши разработчики были более довольны идеей удаления веток.
Превратить их в теги
В Git теги в основном совпадают с ветками, это просто метка в коммите. Разница в том, что они не двигаются. Сделайте метку на ветке, затем удалите ветку. Тег будет ссылаться на коммиты и предотвращать их сборку мусора.
git tag <tag> <branch>
git branch -d <branch>
Вы можете объединить это с ответом Маора и организовать теги в каталог, например archived_branches/.
Если кто-то хочет работать с этой заархивированной веткой, он может создать ветку из тега и удалить тег.
git checkout -b <tag> <branch>
git tag -d <tag>
Это очень дешевый процесс в Git.
В конце концов, когда никто не использовал эти заархивированные теги через некоторое время, вы можете удалить их как мертвые. Согласитесь с датой создания архива тегов. Отметьте его в общем календаре.
Утилизация содержимого ветки
Обязательно проверьте содержимое ветки на предмет спасения. Если есть, вы можете сделать его активной ветвью, или вишня полезные биты.
Получите людей, которые хотят держать старые ветви вокруг "на всякий случай", чтобы сделать эту работу.
Удалить все, что было объединено
Вы можете проверить, какие ветви были объединены с мастером git branch --merged master. Удалить объединенные ветви. Связи между коммитами сохранят то, что было ветвью, а коммит слияния сохранит то, чем была эта ветвь. Например ...
A - B - C --------- G - H - I [master]
\ /
D - E - F
D - E - F - коммиты в ветке, а G - коммит слияния. Сообщение коммита слияния, если они все делали правильно, будет содержать какую-то ссылку о том, над чем они работали. Может быть, ссылка на трекер. См. мой ответ на Почему я должен удалять ветви объектов при слиянии с мастером? для более подробной информации.
Используйте reflog
Git имеет тенденцию хранить старые коммиты около двух недель перед сборкой мусора, так что это дает вам некоторый буфер. Вы можете записать их идентификаторы коммитов или использовать reflog для их восстановления. Восстановить их так же просто, как git branch <name> <commit id>.
Использовать резервные копии
Резервные копии вашего хранилища (у вас есть резервные копии, верно?) Дают вам еще один буфер.
Сделать клона
Наконец, вы можете сделать клон хранилища непосредственно перед тем, как удалить старые ветви и спрятать их где-нибудь. Если выясняется, что старую ветвь нужно восстановить, ее можно извлечь из этого архива.
Но, вероятно, никто не будет снова думать о тех старых ветвях.