Как убрать извлеченные пульты на Git? - PullRequest
0 голосов
/ 28 декабря 2018

Я получил несколько удаленных веток, например, git fetch jason sprint-36.Я приложил снимок экрана (красные - это пульты):

enter image description here

Как мне остановить отслеживание / удалить пульт из моего списка?Например, 4 месяца назад я сделал git fetch ken retain-cycle-fix, и я никогда больше не получу и не посмотрю эту ветку, как мне ее удалить?

Ответы [ 2 ]

0 голосов
/ 28 декабря 2018

Если он также удален на пульте дистанционного управления, вы можете просто использовать

git fetch --prune

, и он просто обрезает все ветви, которых больше нет в пультах.

С другой стороны, если он не удален в удаленном хранилище и вы никогда больше не получите его, вы можете просто использовать

git branch -rd <branch_name>
0 голосов
/ 28 декабря 2018

Чтобы удалить имя для удаленного отслеживания, например 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 не совпадает со ссылкой.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...