Удалить ветки удаленного отслеживания в Git
В этом посте мы обсудим, как удалить ветки удаленного отслеживания в git.
1. git-push
The git-push Команда обычно используется для отправки локальных изменений в удаленный репозиторий, но также может использоваться для удаления удаленных веток.
Мы можем сделать это с помощью git push с -d вариант, псевдоним для —delete . Это удаляет указанную ветку из удаленного репозитория. Полная команда:
git push [-d | --delete]
Чтобы получить список всех удаленных ветвей, вы можете использовать git-branch команда с -r вариант, псевдоним для —remotes . Возможно, вы захотите сначала синхронизироваться с удаленным сервером, используя git fetch .
git fetch
git branch (-r | --remotes)
git push origin --delete vlang
Это показано ниже, где ветвь vlang удаляется из источника удаленного сервера.
В качестве альтернативы вы можете поставить перед всеми ссылками двоеточие.
Следующая команда удалит ссылку, соответствующую ним в исходном репозитории.
2. git-ветка
Вы также можете удалить удаленные ветки с помощью git-branch команду, используя -r вариант с -d вариант.
git branch -d -r
Это показано ниже:
Обратите внимание, что удалять ветки удаленного отслеживания имеет смысл только в том случае, если они больше не существуют в удаленном репозитории или если git fetch настроен не извлекать их. Вы можете использовать чернослив подкоманда git-remote для очистки устаревших веток удаленного слежения.
git remote prune origin
В качестве альтернативы вы можете использовать get-fetch команда с —prune возможность удалить любые ссылки на удаленное отслеживание, которые больше не существуют на удаленном компьютере.
git fetch --all --prune
Это все, что касается удаления веток удаленного отслеживания в Git.
Оценить этот пост
Средний рейтинг 4.68 /5. Подсчет голосов: 25
Голосов пока нет! Будьте первым, кто оценит этот пост.
Сожалеем, что этот пост не оказался для вас полезным!
Расскажите, как мы можем улучшить этот пост?
Спасибо за чтение.
Пожалуйста, используйте наш онлайн-компилятор размещать код в комментариях, используя C, C++, Java, Python, JavaScript, C#, PHP и многие другие популярные языки программирования.
Как мы? Порекомендуйте нас своим друзьям и помогите нам расти. Удачного кодирования 🙂
Подписывайся
0 Комментарии
Встроенные отзывы
Просмотреть все комментарии
Загрузить больше комментариев
Просматривать
Подпишитесь на новые публикации
- Все проблемы
- Практика DSA
- 100 самых популярных задач
- 50 лучших классических задач
- Лучшие алгоритмы
- Компилятор С/С++
- Компилятор Java
- Компилятор Python
- Компилятор JavaScript
- компилятор PHP
- Компилятор C#
- Свяжитесь с нами
- Политика конфиденциальности
- условия обслуживания
- Подпишитесь на новые публикации
Techie Delight © 2023 Все права защищены.
Этот веб-сайт использует файлы cookie. Используя этот сайт, вы соглашаетесь с использованием файлов cookie, нашей политикой, условиями авторского права и другими условиями. Читайте наши Политика конфиденциальности. Понятно
Удаление репозитория из панели Репозитории Git
Если по какой-то причине удалённый репозиторий вам больше не нужен (например, вы сменили сервер, или больше не используете определённое зеркало, или, возможно, контрибьютор перестал быть активным), вы можете выполнить контекстную команду Удалить удаленный репозиторий , чтобы репозиторий не присутствовал в панели Репозитории Git .
git rm
В начале использования Git часто возникает вопрос: «Как заставить Git больше не отслеживать какой-либо файл или несколько файлов?» Чтобы удалить файлы из репозитория Git, можно воспользоваться командой git rm . Ее действие противоположно действию git add.
Обзор команды git rm
Команда git rm позволяет удалять отдельные файлы или группы файлов. Основное назначение git rm — удаление отслеживаемых файлов из раздела проиндексированных файлов Git. Кроме того, с помощью git rm можно удалить файлы одновременно из раздела проиндексированных файлов и рабочего каталога. Удалить с ее помощью файл только из рабочего каталога нельзя. Файлы, в отношении которых выполняется команда, должны быть идентичны файлам в текущем указателе HEAD . В случае расхождений между версией файла из указателя HEAD и версией из раздела проиндексированных файлов или рабочего дерева Git заблокирует удаление. Такая блокировка является механизмом безопасности, который предотвращает удаление изменений в процессе их внесения.
Обратите внимание, что git rm не удаляет ветки. Подробнее об использовании веток Git см. здесь.
Использование
Указывает файлы, подлежащие удалению. Можно указать один файл, несколько файлов через пробел ( file1 file2 file3 ) или шаблон подстановки ( ~./directory/* ).
-f
--force
Параметр -f применяется для отключения проверки безопасности, с помощью которой Git обеспечивает соответствие файлов в указателе HEAD текущему содержимому раздела проиндексированных файлов и рабочего каталога.
Связанные материалы
Шпаргалка по Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
-n
--dry-run
Параметр dry run является защитным механизмом. Он позволяет выполнить пробный запуск команды git rm без удаления файлов. В выходных данных отображаются файлы, которые должны были быть удалены.
Параметр -r — это сокращение от слова recursive. При выполнении команды git rm в рекурсивном режиме она удаляет не только каталог назначения, но и все содержимое его вложенных каталогов.
Параметр разделителя позволяет явным образом отличить список имен файлов от аргументов, передаваемых команде git rm . Разделитель полезен, когда какие-либо из файлов имеют имена, аналогичные параметрам команды.
--cached
Параметр cached указывает, что должны быть удалены только файлы, находящиеся в разделе проиндексированных файлов. Файлы в рабочем каталоге при этом остаются нетронутыми.
--ignore-unmatch
Этот параметр заставляет команду завершиться со статусом sigterm, равным 0, даже если файлы, указанные для удаления, не найдены. Sigterm — это код состояния в Unix. Код 0 указывает на успешный вызов команды. Параметр —ignore-unmatch может быть полезен, если команда git rm используется в составе скрипта оболочки, который должен обеспечивать корректную обработку отказа.
-q
--quiet
Параметр quiet скрывает вывод команды git rm . Как правило, команда выводит по одной строке на каждый удаленный файл.
Отмена изменений, внесенных командой git rm
Изменения, вносимые при выполнении команды git rm , не являются окончательными. Эта команда обновляет раздел проиндексированных файлов и рабочий каталог. Изменения не сохранятся, пока не будет создан новый коммит и они не будут добавлены в историю коммитов. Так что изменения, внесенные командой git rm, можно «отменить» с помощью стандартных команд Git.
git reset HEAD
Команда git reset восстановит раздел индексированных файлов и рабочий каталог до коммита HEAD . В результате изменения, внесенные командой git rm , будут отменены.
git checkout .
Такого же результата можно добиться с помощью команды git checkout: она восстановит последнюю версию файла из указателя HEAD .
Если после выполнения git rm был создан новый коммит, из-за которого удаление сохранилось, можно воспользоваться командой git reflog , чтобы найти ссылку, предшествующую выполнению git rm . Подробнее об использовании git reflog см. здесь.
Пояснения
Аргумент , переданный команде, может содержать точные пути, шаблоны поиска файлов или точные имена каталогов. При выполнении команды удаляются только пути, зафиксированные в репозитории Git посредством коммитов.
В шаблонах поиска файлов можно задавать имена каталогов. При использовании шаблонов поиска следует быть внимательным. Рассмотрим примеры: directory/* и directory* . Использование первого шаблона приведет к удалению всех файлов в каталоге directory/ , тогда как второй вызовет удаление всех каталогов, имя которых начинается на directory — например, directory1 , directory2 , directory_whatever и т. д., что может быть нежелательным.
Область действия команды git rm
Действие команды git rm распространяется только на текущую ветку. Удаление выполняется только в деревьях рабочего каталога и раздела проиндексированных файлов. Удаление файла не сохраняется в истории репозитория до тех пор, пока не создан новый коммит.
Почему следует использовать git rm, а не rm
Репозиторий Git обнаруживает выполнение стандартной команды оболочки rm для отслеживаемого им файла и соответствующим образом обновляет рабочий каталог. Но раздел проиндексированных файлов не обновляется. Чтобы внести в него изменения, для удаленных путей к файлам необходимо дополнительно выполнить команду git add . Команда git rm уменьшает количество действий, поскольку обновляет при удалении и рабочий каталог, и раздел проиндексированных файлов.
Примеры
git rm Documentation/\*.txt
В данном примере шаблон поиска файлов используется для удаления всех файлов *.txt в каталоге Documentation и всех его подкаталогах.
Обратите внимание, что символ звездочки * здесь экранируется символами косой черты. Это сделано, чтобы оболочка не расширяла шаблон. В таком варианте он включает только пути к файлам и подкаталогам, находящимся в каталоге Documentation/ .
git rm -f git-*.sh
В этом примере команда выполняется с параметром force для всех файлов, соответствующих шаблону подстановки git-*.sh . Параметр force явным образом удаляет целевые файлы из рабочего каталога и раздела проиндексированных файлов.
Удаление файлов, которых уже нет в файловой системе
В разделе «Почему следует использовать git rm , а не rm » говорилось о том, что команда git rm предусмотрена для удобства: она сочетает функции стандартной команды оболочки rm и команды git add , позволяя удалить файл из рабочего каталога и раздела проиндексированных файлов. Если удалить несколько файлов с помощью стандартной команды оболочки rm , состояние репозитория может стать проблематичным.
Если требуется записать все явным образом удаленные файлы в следующий коммит, можно выполнить команду git commit -a . Она внесет все события удаления в раздел проиндексированных файлов для подготовки к следующему коммиту.
Если же стоит задача безвозвратно удалить файлы, удаленные с помощью команды оболочки rm , нужно воспользоваться следующей командой:
git diff --name-only --diff-filter=D -z | xargs -0 git rm --cached
Эта команда создаст список удаленных файлов из рабочего каталога и передаст его команде git rm —cached , которая обновит раздел проиндексированных файлов.
Команда git rm: заключение
Команда git rm выполняет действия над двумя главными деревьями управления внутренним состоянием Git: рабочим каталогом и разделом проиндексированных файлов. Команда git rm позволяет удалять файлы из репозитория Git. Это удобный инструмент, объединяющий функции стандартной команды оболочки rm и команды git add : сначала git rm удаляет целевой объект из файловой системы, а затем добавляет событие удаления в раздел проиндексированных файлов. Эта команда — одна из многих, которые можно использовать для отмены изменений в Git.
Как удалить коммит в удаленном репозитории?
Сделал коммит. Не заметил как в него попала пара сотен МБт дерьмища. Потом запушил и тут я обнаружил свой косяк. Подскажите, как в удаленном и локальном репозитории удалить последний коммит с сохранением изменений в рабочей дирректории?
git reset —hard HEAD~1 неподходит, т.к. возвращает меня к комиту 3х месячной давности! Нужно удалить коммит, но чтобы все изменения в рабочей директории сохранились! Спасибо!
NkDev
09.06.18 12:05:29 MSK
Чем не устраивает —soft?
oldstable ★
( 09.06.18 12:08:21 MSK )
1. удаляешь коммит локально (например, через git rebase -i)
2. git push -f origin branchname
waker ★★★★★
( 09.06.18 12:08:24 MSK )
Это банальный и частый вопрос, ответ на который находится за пару минут в гугле.
Deleted
( 09.06.18 12:10:54 MSK )
reset без —hard. —soft/—mixed на выбор. Далее вычищаешь всё ненужно, commit, push -f
Deleted
( 09.06.18 12:11:04 MSK )
git revert HEAD git push
. и нет проблем синхронизации.
KennyMinigun ★★★★★
( 09.06.18 12:31:29 MSK )
Последнее исправление: KennyMinigun 09.06.18 12:32:16 MSK (всего исправлений: 1)
Ответ на: комментарий от KennyMinigun 09.06.18 12:31:29 MSK
Смотри-ка, сколько в трэде любителей push —force!
Deleted
( 09.06.18 12:33:56 MSK )
Ответ на: комментарий от KennyMinigun 09.06.18 12:31:29 MSK
. и есть огромные проблемы с размером репозитория!
в него попала пара сотен МБт дерьмища
EXL ★★★★★
( 09.06.18 12:43:13 MSK )
EXL ★★★★★
( 09.06.18 12:46:15 MSK )
Ответ на: комментарий от oldstable 09.06.18 12:08:21 MSK
или git commit —amend
i-rinat ★★★★★
( 09.06.18 12:47:28 MSK )
Через git rm удалить всё ненужное.
Потом git commit —amend, чтобы ранее добавленное и свежеудалённое аннигилировались.
Потом push —force, чтобы перезаписать последний коммит.
Profit!
akk ★★★★★
( 09.06.18 12:53:35 MSK )
Ответ на: комментарий от Deleted 09.06.18 12:33:56 MSK
А как ещё ты предлагаешь удалять часть истории?
Miguel ★★★★★
( 09.06.18 12:54:48 MSK )
Ответ на: комментарий от Miguel 09.06.18 12:54:48 MSK
В сабжевом случае хорошо подходит это. В том и цимес же, что историю на remote удолять не надо )
Deleted
( 09.06.18 13:13:37 MSK )
Ответ на: комментарий от akk 09.06.18 12:53:35 MSK
+1, сам так делаю, когда накосячу 🙂
htower_ ★★
( 09.06.18 13:21:51 MSK )
Не заметил как в него попала пара сотен МБт дерьмища
Кстати, ТС, а как это случилось? Убогий gitignore?
Deleted
( 09.06.18 13:23:59 MSK )
Ответ на: комментарий от Deleted 09.06.18 13:13:37 MSK
Каким образом это подходит, если при этом подходе до скончания времен при любом git clone будет тянутся
EXL ★★★★★
( 09.06.18 13:33:15 MSK )
Последнее исправление: EXL 09.06.18 13:33:28 MSK (всего исправлений: 1)
Ответ на: комментарий от Deleted 09.06.18 13:13:37 MSK
Во-первых, вопрос именно о том, как её удалить.
Во-вторых, почему не надо-то? Мастер не стоит, но пока это моя бранча — что хочу, то и ворочу.
Miguel ★★★★★
( 09.06.18 13:33:31 MSK )
Ответ на: комментарий от Miguel 09.06.18 13:33:31 MSK
пока это моя бранча — что хочу, то и ворочу.
Даже если твой бранч уже смержили в мастер?
tailgunner ★★★★★
( 09.06.18 13:34:24 MSK )
Ответ на: комментарий от EXL 09.06.18 13:33:15 MSK
Не так уж и много + clone не каждый день/неделя/месяц.
А так да, на это внимания не обратил
Deleted
( 09.06.18 13:36:36 MSK )
Ответ на: комментарий от Miguel 09.06.18 13:33:31 MSK
Вот здесь не понял. С чего ты взял, что это не общая ветка?
Deleted
( 09.06.18 13:38:12 MSK )
Ответ на: комментарий от Deleted 09.06.18 13:36:36 MSK
Лучше перезапись последнего коммита с push —force в remote, чем мусор на несколько сотен мегабайт в репозитории, который поди
И за убожество вида revet ‘my shit commit’ в истории тоже надо линчевать.
EXL ★★★★★
( 09.06.18 13:42:22 MSK )
Ответ на: комментарий от EXL 09.06.18 13:42:22 MSK
И за убожество вида revet ‘my shit commit’ в истории тоже надо линчевать
Линчевать много за что можно, но иногда выбора нет. К тому же, смотря на сколько
В случае тонких ошибок полезно это в репе оставить, в назидание, так сказать. К сабжу это не относится, но там по-другому можно повернуть: какого хера gitignore не заюзали? А скорее всего — заюзали, но там шаблонов подходящих не было(на все случаи не напасёшься). Было бы неплохо иметь, скажем gitaccept, указывая какие файлы _отслеживать_, а не какие игнорировать. Через gitignore тоже можно, но там костыльно — сомневаюсь, что пригодно для продакшена. Сколько здесь кандидатур на линчевание?)
Deleted
( 09.06.18 13:51:34 MSK )
Ответ на: комментарий от Deleted 09.06.18 13:51:34 MSK
Из зол вида «сотни МБ хлама в БД до скончания веков» и «перезапись последнего запушенного коммита» — первая куда как больше.
Я очень сильно сомневаюсь, что у ТС огромный и оверпопулярный репозиторий, который форкают каждый день и каждый час отправляют в него PR’ы. А потому этот —force скорее всего никто кроме TC и не заметит.