Чтобы удалить имя для удаленного отслеживания, например remotes/jason/sprint-36
или remotes/ken/retain-cycle-fix
, вы можете использовать git branch -r -d
:
$ git branch -r -d remotes/jason/sprint-36
, например.Тем не менее, редко есть какая-либо причина, чтобы сделать это, потому что если вы запустите git fetch jason
, вы немедленно повторно получите все ваши remotes/jason/
имена удаленного отслеживания.
Чтобы удалить весь удаленныйвместе со всеми его именами для удаленного отслеживания используйте git remote remove
или git remote rm
(два имени для одной и той же подкоманды).
Полезные базовые знания (ничего из этого не требуется для чтения, вы можете остановитьздесь)
Здесь стоит отметить несколько вещей, ни одна из которых не является прямым ответом на вопрос, но полезна для полноты:
Во-первых, Git называет эти вещи имена веток для удаленного отслеживания , но на самом деле они не ветви , потому что ветвь - или, по крайней мере, ветвь name - это имя, которое вы можете дать git checkout
, что приводит к присоединению HEAD
к этому имени.
То есть после git checkout master
или, в вашем случае, git checkout sprint-41
, вы будете "на" этой ветви.Команда git status
скажет on branch <em>branch</em>
, и новые сделанные вами коммиты автоматически изменят имя этой ветви, чтобы оно указывало на только что сделанный новый коммит.Ничто из этого не относится к этим именам удаленного отслеживания, поэтому я решил назвать их «именами удаленного отслеживания», полностью исключив слово branch .
У них есть полные имена.Полное имя remotes/jason/sprint-36
действительно refs/remotes/jason/sprint-36
.Полное имя может быть сокращено благодаря шестиэтапному процессу разрешения имен, описанному в документации gitrevisions : jason/sprint-36
обычно работает, а если нет, remotes/jason/sprint-36
обычно работает, но если ни то, ни другоеИз этих работ форма полного имени всегда работает.
По какой-то причине git branch -r
указывает сокращенную версию без remotes/
, а git branch -a
отображает сокращенную версию с remotes/
.
Смысл имени для удаленного отслеживания заключается в том, чтобы отслеживать имя, в частности, имя ветви, на пульте дистанционного управления.Поэтому git fetch
обновляет эти имена для удаленного отслеживания.По крайней мере, так с версии Git 1.8.4.
Как и все ссылки, имя для удаленного отслеживания просто записывает хэш-идентификатор одного отдельного коммита.Если для этого коммита достижимо из любого другого имени, имя удаленного отслеживания просто указывает на этот конкретный коммит.Если фиксация не недоступна для любого другого имени, имя удаленного отслеживания сохраняет этот коммит и его предшественников (родителей, бабушек и дедушек и т. Д. В истории) живыми в вашем хранилище.(См. Ссылку на http://think -like-a-git.net / для определения достижимости.)
Это означает, что удаление имени удаленного отслеживания не сохранитлюбой пробел, если это имя не является only способом для достижения некоторых коммитов, которые занимают много места в вашем хранилище.Если имя удаленного отслеживания указывает на коммит, который сохраняется другими коммитами и / или именами, вы, безусловно, не сохраните ничего, удалив его, кроме некоторого пространства экрана в выводе git branch
и т. П. 1
Когда вы запускаете git fetch <em>remote</em>
без дополнительных аргументов, Git будет извлекать и обновлять ссылки, перечисленные в настройках remote.<em>remote</em>.fetch
(используйте git config --get-all remote.<em>remote</em>.fetch
для их просмотра).При запуске git fetch <em>remote</em> <em>refspec1</em> [<em>refspec2</em> [...]]
, git fetch
будет обновляться только на основе заданных refspec
аргументов.
1 Технически, вы можете сохранить один диск или около того, если имя удаленного отслеживания в данный момент распаковано.Однако большинство имен для удаленного отслеживания в основном упакованы (хранятся в .git/packed-refs
вместе со многими другими именами).
Получите с помощью --prune
или fetch.prune
Вы можетерегулярно запускайте git fetch
или git fetch origin
, чтобы обновить все ваши имена для удаленного отслеживания для origin
.(Я делаю это, например. Это очень безопасно делать в любое время.) Когда вы это делаете, вы получаете много имен для удаленного отслеживания.
Evслучайно некоторые из этих имен могут исчезнуть из origin
.Однако они не будут автоматически исчезать из ваших собственных имен для удаленного отслеживания.Чтобы заставить их уйти автоматически , используйте git fetch --prune origin
или настройте fetch.prune
на true
, что означает git fetch
по умолчанию использование --prune
.Замените origin
здесь любым пультом, таким как jason
или ken
, чтобы обновить все с помощью сокращения.(Но если вам не нравится обновлять все, не делайте этого вообще - это настройка «все в одном», которая создает или обновляет все имена удаленного отслеживания для этого удаленного устройства, удаляя при этом все мертвые.)
Refspecs, или, больше о git fetch
es, которые вы используете
В одном из приведенных выше примеров вы запустили:
git fetch jason sprint-36
Это использует sprint-36
как refspec.Обычно refspec состоит из двух имен, разделенных двоеточием, например, refs/heads/master:refs/remotes/origin/master
.Пропуск двоеточия и второго имени делает что-то особенное - и отличается от git fetch
против git push
.Для git push
пропуск двоеточия означает использовать одно и то же имя с обеих сторон , но для git fetch
это означает не использовать никакого имени на моей стороне .
Вот где все становится странным, и именно поэтому я должен был упомянуть Git до 1.8.4 и 1.8.4 и позже в одном из этих пунктов.Здесь есть историческая странность.
Каждый git fetch
записывает информацию о том, какие имена были выбраны, и соответствующие хэш-идентификаторы объектов Git, в специальный файл в .git
с именем FETCH_HEAD
,Этот файл почти такой же, как ссылка, но не совсем, потому что он может и часто содержит несколько строк, с большим, чем просто хэш-идентификатором в каждой строке.По сути, git fetch
начинается с вывода git ls-remote
(попробуйте это на пульте дистанционного управления - он просто печатает данные в окне терминала), выясняет, что нужно извлечь, а затем сохраняет что-то очень похожее в .git/FETCH_HEAD
.
В старые добрые времена, когда Git было особенно трудно использовать, это было только место git fetch
, сохраняющее свою информацию.Вы должны были немедленно выловить что-нибудь полезное и сохранить это самостоятельно.Сценарий git pull
сделал это для вас.Это по-прежнему работает , потому что, как и Intel, парни из Git любят сохранять «обратную» в «обратной совместимости».11
Начиная с Git 1.8.4, все изменилось: Git научился использовать настройку fetch
для этого пульта для обновления соответствующих ветвей удаленного отслеживания.
Между тем - тогда истина ивсе еще верно сейчас - если вы используете форму с двумя именами, например:
git fetch jason sprint-36:rhs
git fetch
будет пытаться записать то, что он выбрал, используя левое имя, sprint-36
(сопоставляется со списком, которыйвыливается из git ls-remote jason
так, что оно становится refs/heads/sprint-36
) для ветки, тега или любого другого имени в вашем собственном хранилище.Здесь я использовал rhs
в качестве имени справа.Это имя не является полностью определенным (например, не начинается с refs/heads/
) и, вероятно, в настоящее время не существует в качестве имени в вашем хранилище, поэтому Git будет использовать реплику refs/heads/
из вашего jason
удаленно для создания новой ветви, refs/heads/rhs
, в вашем собственном репозитории.
Пока ваш Git версии 1.8.4 или новее, он будет также произвольно создавать или обновлять refs/remotes/jason/sprint-36
в настоящее время.
Следовательно, выборка с refspec, который содержит двоеточие и имя в правой части, может создать или обновить две ссылки в вашем хранилище.Как правило, это будет имя ветки, например refs/heads/rhs
или refs/heads/sprint-36
.Другим будет имя удаленного слежения, например, refs/remotes/jason/sprint-36
, управляемое с помощью настройки remote.jason.fetch
в вашем .git/config
.
Вы можете изменить настройку remote.jason.fetch
.Если вы это сделаете, это изменит действие git fetch jason
: без refspecs, Git подчиняется настройке fetch.Это также потенциально меняет действие git fetch jason sprint-36
: если refs/heads/sprint-36
больше не сопоставляется с именем удаленного отслеживания, имя удаленного отслеживания не будет создано или обновлено.
и когда все это полезно, трудно сказать.(Дизайн действительно ориентирован на --single-branch
клонов, а не на причудливые конфигурации, управляемые пользователями.) Тем не менее, это основной механизм: refspecs проходят через refmaps (который я не буду пытаться определить здесь,но они довольно плохо описаны в документации git fetch
), которая по умолчанию построена из настроек удаленного доступа fetch
.
Обратите внимание, что без начального знака плюс +
, ссылка типа sprint-36:rhs
является принудительным обновлением.Такое обновление выполняется только в том случае, если обновление приводит к операции ускоренной перемотки вперед.Это, на самом деле, полезно, потому что это означает, что вы можете быстро пересылать свои собственные нетекущие ветки из своих собственных ветвей или имен удаленного отслеживания.Вы можете сделать это через git fetch
или git push
, используя .
в качестве имени удаленного, поскольку .
означает этот репозиторий Git:
git fetch . refs/remotes/origin/master:refs/heads/master
или:
git push . refs/remotes/origin/master:refs/heads/master
переместит вашу собственную master
в соответствии с origin/master
, без необходимости покидать текущую ветвь, отличную от master
.(Это не сработает, если вы сами по себе master
. Есть хитрый способ заставить его работать, но не делайте этого!)
(Вам редко приходится прописывать полную веткуимена здесь, но на всякий случай это хорошая идея - раздражает, когда Git не совпадает со ссылкой.)