Как очистить удаленный репозиторий git
Как удалить Git Remote
Главное меню » Linux » Как удалить Git Remote
Git remote – это указатель, который ссылается на другую копию хранилища, которая обычно размещается на удаленном сервере.
Как правило, при работе с Git у вас будет только один удаленный узел с именем origin и разные ветви для разных функций и сред. Origin – это имя удаленного, которое автоматически создается при клонировании репозитория и указывает на клонированный репозиторий.
Однако при совместной работе над проектом с группой людей использование нескольких пультов Git очень удобно. Удаленный репозиторий может быть размещен на службе хостинга Git, такой как GitHub, GitLab и BitBucket, или на вашем частном сервере Git.
Если удаленный репозиторий перенесен на другой хост, или участник прекратил делать вклады, вы можете удалить удаленный URL из своего репозитория.
Удаление Git Remote
Чтобы удалить удаленный, перейдите в каталог, в котором хранится ваш репозиторий, и используйте команду git remote rm(или git remote remove), за которой следует имя удаленного:
Например, чтобы удалить имя удаленного testing, вы должны набрать:
git remote rm удаляет все ссылки на удаленный репозиторий. Но он не удаляет хранилище с удаленного сервера.
Чтобы убедиться, что Git Remote был успешно удален, используйте команду git remote для просмотра списка удаленных подключений:
Вывод будет выглядеть примерно так:
Если remote, который вы пытаетесь удалить, не существует, Git выведет сообщение об ошибке:
Возможно, вы опечатали имя или remote уже удален.
Вывод
Используйте команду git remote rm для удаления удаленного из хранилища.
Если вы столкнулись с проблемой или у вас есть отзыв, оставьте комментарий ниже.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
очистить гит репозиторий от удалённых файлов
Можно ли как-то почистить репозиторий от удалённых файлов и их истории?
3 ответа 3
Для большого количества файлов или небольшого репозитория можно попробовать git filter-branch (см ответ от Arhad).
Из базовых примеров:
Удаления файлов по маске:
Удаление папки целиком
Удаление больших файлов
BFG по умолчанию не удаляет блобы в текущей ветке ( HEAD ), так что она идеально подходит для массовых чисток и переписывания истории без риска запороть последний коммит.
В качестве гайда можно воспользоваться справкой GitHub по чистке репозиториев:
Для того, чтобы удалить все упоминания конкретного файла из истории репозитория необходимо воспользоваться командой git filter-branch :
где — это путь до удаляемого файла относительно текущей папки (не корня репозитория!).
Учтите, что эта команда занимается переписыванием истории. То есть она берёт старое дерево и переносит его в новую копию, коммит за коммитом, после чего переназначает текущую указатель-ветку. Поэтому она работает очень медленно (около секунды на перенос одного коммита).
Затем надо удалить пустые коммиты, образовавшиеся на месте тех, в которых были изменения только удалённых файлов:
После переписывания истории надо убрать все оставшиеся хвосты, чтобы как можно скорее уменьшить размер репозитория:
Удаляем все недостижимые объекты (и упаковываем оставшиеся):
Шпаргалка по Git. Решение основных проблем
Восстановление накопленных изменений
В том случае, если изменения, внесённые пользователем, находятся в режиме накопления, применить их к ветке можно с помощью команды git stash apply. Также можно запустить git diff — эта команда поможет выявить различия. Для того, чтобы затем избавиться от накопленных данных, нужно запустить команду:
Если существует более одного накопления, найти нужное можно с помощью команды:
git stash list затем можно применить его, воспользовавшись его индексом:
Необходимо учитывать, что отсчёт индексов ведётся от нуля.
Восстановление удалённого тега
В том случае, если необходимо восстановить случайно удалённый тег, начать можно с его поиска:
После того, как нужный тег найден, его следует восстановить:
Восстановление удалённого файла
Если вы случайно удалили файл, его можно быстро восстановить:
Если требуется восстановить файл из конкретной временной точки истории коммитов, следует узнать хеш нужного коммита и запустить команду:
Восстановление удалённой ветки
С помощью комманды git reflog можно узнать хеш (SHA1) последнего коммита в удалённой ветке. Скопируйте этот хеш и используйте в команде:
После этого восстановить удалённую ветку можно будет вот такой командой:
Изменение сообщения коммита перед его отправкой
Сообщение можно изменить и напрямую с помощью команды
Изменение сообщения коммита после его отправки
Предупреждение: подобная насильная перезапись может привести к потери коммитов из внешней ветки, если с ней давно не было синхронизации, соблюдайте осторожность.
Использование алиасов команд в командной строке
Устали каждый раз печатать git status? Этой команде можно присвоить простой алиас, который проще и быстрее вбивать в git.
— теперь нужно писать только git st
Можно пойти дальше и присвоить алиасы более сложным командам:
Теперь алиас git logme будет выводить все наши коммиты.
Коммит в неправильную ветку
Нужно переключиться на новую ветку, которую вы забыли предварительно создать:
А затем переключиться к оригинальной ветке:
. и «откатиться» до последнего коммита, который нужно сохранить.
Чтобы это сделать, можно воспользоваться командой git log и сохранить хеш (SHA1) последнего коммита, который нужно оставить.. Например, это a31a45c.
Предупреждение: Убедитесь в том, что никто не отправлял коммиты в оригинальную ветку во время выполнения вышеописанных процедур, в противном случае эти изменения будут потеряны!
Обновление конкретного подмодуля
Чтобы обновить конкретный подмодуль в репозитории, нужно добавить путь к подмодулю:
Откат к конкретному коммиту в истории
Если вас не очень беспокоят изменения в локальном репозитории, то можно «откатиться» к конкретному коммиту в истории с помощью команды:
Эта команда установит HEAD на конкретный коммит. Также можно воспользоваться хешем коммита.
Отмена коммита до публикации изменений
Если вы сделали коммит, который впоследствии понадобилось отредактировать или полностью стереть, поможет команда git reset.
Будьте осторожны используя второй вариант, поскольку изменения ваших локальных файлов будут потеряны.
Чтобы сохранить сообщение коммита, наберите: :
Отмена коммита после отправки его в master-репозиторий
Рассмотрим процедуру возврата одного или нескольких коммитов, которые нужно стереть из удалённой ветки. Обозначить конкретный коммит можно с помощью его хеша:
Отмена только коммита, который является вторым после последнего:
Простая отмена последнего коммита:
Отмена локальных изменений файлов
Простейшим способом избавиться от нежелательных изменений для файлов и папок является восстановление состояния последнего коммита. Сделать это можно с помощью специальной команды:
Кроме того, можно восстановить конкретный путь к файлу:
Отображение всех коммитов одного файла
Аргумент —follow позволяет вывести все изменения над файлом, даже если в процессе работы он был переименован.
Отображения числа коммитов от каждого участника
Хотите узнать, сколько коммитов сделал каждый участник команды?
Отобразить коммиты, содержащие удалённые файлы
Узнать, в каких коммитах содержатся удалённые файлы, можно с помощью команды:
Она покажет список коммитов, в которых удалялись файлы.
Отсортировать коммиты по автору
Чтобы вывести список коммитов, отфильтрованных по автору, следует воспользоваться следующей командой:
Очистка всех скрытых состояний
Очистить все скрытые состояния можно следующей командой:
Переименование локальной и удалённой ветки
Предложим, у вас есть ветка «fix-bug25», которую вы захотели переименовать в «hotfix-users». Прежде всего, нужно будет изменить локальную ветку:
А затем — удалённую ветку: переименовать её напрямую нельзя, поэтому нужно будет её удалить, и затем опубликовать заново уже с новым именем. Прежде чем приступать к этим процедурам, следует убедиться, что никто из членов команды не работает с этой веткой! Удаляем ветку: git push origin :fix-bug25
А теперь заново публикуем её с новым именем: git push origin hotfix-users
Переименование тега
Чтобы переименовать существующий тег:
Перестать отслеживать существующие файлы
Если вы хотите перестать отслеживать файлы, которые уже есть в репозитории, но при этом желаете сохранить его локально, осуществите коммит изменений и запустите команду:
Она удалит изменённые файлы из зоны подготовленных файлов (staging area). Затем нужно запустить команду:
и отправить изменения.
Подготовка удалённых файлов
Чтобы подготовить к коммиту файлы и папки, которые были удалены локально, можно использовать специальную команду:
Если требуется подготовить только используемый в данный момент путь, воспользуйтесь командой
Поиск конкретного сообщения во всех коммитах
Чтобы найти конкретный текст сообщения коммита, соответствующий регулярному выражению, нужно воспользоваться командой
Пометить конфликтующий файл, как разрешённый
Чтобы пометить один или несколько конфликтующих файлов, как разрешённые, чтобы их можно было нормально изменять, воспользуйтесь командой:
Затем можно запустить git commit, чтобы разрешить конфликты и опубликовать изменения.
Просмотр всех неотправленных коммитов
Чтобы просмотреть все коммиты, которые ещё не были отправлены в соответствующие ветки, воспользуйтесь следующей командой:
Кроме того, можно использовать:
Просмотр старой ревизии файла
Существует возможность просмотреть содержимое файла в конкретный момент времени в прошлом. Для этого нужно использовать команду:
Публикация локальной ветки для удалённого редактирования
Если вы создали локальную ветку, и хотите, чтобы другие пользователи могли с ней работать, воспользуйтесь командой:
Теперь они тоже смогут вносить изменения в эту ветку.
Сброс локальной ветки до состояния удалённой
В том случае, если отсутствуют изменения, которые необходимо сохранить, сбросить локальную ветку до состояния удалённой можно с помощью двух простых команд.
Прежде всего нужно получить свежие обновления из удалённой ветки:
А затем нужно сообщить git, что локальную ветку следует «откатить» до состояния удалённой:
Синхронизировать ветку с master-репозиторием
Чтобы синхронизировать последние изменения в репозитории master (или с любой другой веткой, с которой вы работали) необходимо «перебазировать» локальную ветку. Предположим, вы работаете над веткой foobar:
А затем осуществляете «перебазирование»:
После этого будут применены коммиты origin из master. После разрешения конфликтов процесс можно продолжить с помощью команды git rebase —continue. Теперь можно продолжать работу над своей веткой или осуществить её слияние (merge) с главным репозиторием.
Слияние локальных изменений с другой веткой
Это можно сделать прямо в процессе стандартного слияния (merge). Вам стоит сохранить историю слияний используя флаг —no-ff, что означает no fast forward.
Перейдите в ветку, в которую будут вливаться изменения, убедитесь в её актуальности и запустите процесс:
Затем появится сообщение о коммите merge X into Y branch, после чего вы можете смело запушить ваше слияние.>
Совмещение двух и более коммитов
Если есть необходимость в совмещении двух последних коммитов, можно использовать команду
После её ввода появятся инструкции по выбору коммитов. В том случае, если необходимо совместить все коммиты с первым старейшим коммитов, то в первой строке нужно написать pick, а для всех остальных коммитов изменить букву на f. Подробнее здесь
Совмещение коммитов по конкретной функции для добавления в ветку релиза
Если вы решите совместить и опубликовать коммиты, то возникнет новый коммит в ветке релиза, поэтому история ветки конкретной функции останется неизменной.
Ниже представлен пример того, как достичь подобного эффекта:
В конечном итоге останется только один коммит в ветке релиза, а история изменений в ветке разработки конкретной функции останется нетронутой.
Создание новой ветки с изменениями текущей
Часто возникает ситуация, при которой пользователи начинают изменять файлы в ветке, чтобы что-то исправить, и лишь позднее вспоминают, что предварительно не создали новую ветку. К счастью, есть способ сделать это уже в процессе:
Эта команда перенесёт файлы из текущей ветки в новую, которую потом уже можно «закоммитить».
Убрать файл из буфера
Чтобы убрать добавленный по ошибке файл из буфера, нужно воспользоваться простой командой:
Удаление внешней ветки
Если вы хотите удалить ветку, введите команду:
Удаление неотслеживаемых файлов и папок
Чтобы удалить неотслеживаемые файлы и папки из рабочей копии наберите следующую команду:
Чтобы в принципе удалить их:
Подсказка: чтобы увидеть, какие файлы являются лишними, перед их непосредственным удалением, наберите:
Удаление старых веток, стёртых из внешнего репозитория
Если ветка удалена из внешнего репозитория, её также можно стереть из локального репозитория с помощью команды
Она удалит старую ветку под названием название-удалённой-ветки, которая уже была стёрта из внешнего репозитория, но всё ещё доступна локально в remotes/название-удалённой-ветки.
Удаление файла из git с сохранением его локальной копии
Для того, чтобы удалить файл из git, но сохранить его локально нужно использовать следующую команду:
Без Гита и жизнь не та
Получите практику в Git на курсах HTML Academy. Мы расскажем всё, что знаем сами, чтобы вы прокачали навыки в веб-разработке.
Спаси щеночка – держи свои git-репозитории в чистоте
Помните, что о каждом бессистемном git-репозитории в мире грустит один щеночек. Вы ведь не хотите расстраивать еще одного?
Бросим все силы на борьбу с собачьей грустью!
Все приведенные в статье советы могут быть использованы как в краткосрочных, так и в долговременных проектах. Они сочетают в себе лучшие практики, а также личный опыт профессиональных разработчиков.
Совет 1. Комментируйте коммиты с умом
Пишите к вашим коммитам короткие и осмысленные сообщения. В идеале они должны быть связаны с тикетами в вашей системе управления проектами. Это позволит легко найти соответствующую задачу и всю необходимую информацию по коммиту.
Например, если вы используете JIRA, начинайте каждый комментарий с префикса JIRA-тикетов. Так вы сможете перейти к задаче простым кликом и получить список всех относящихся к ней коммитов.
Совет 2. Gitflow: действуйте по плану
Если вы незнакомы с Gitflow, то обязательно загляните в руководство Atlassian или наш материал.
Это очень полезная штука, которая помогает придерживаться плана и держать проект в чистоте и порядке независимо от его размера. Использование единого соглашения облегчает работу в команде.
Когда проект поддерживает множество разработчиков, становится трудно отслеживать, где, когда и почему была развернута какая-то ветка. В продакшн может попасть то, что не должно там быть, особенно после мелких правок. Gitflow устанавливает четкие правила работы в git-репозитории проекта и позволяет избежать таких ошибок.
Совет 3. Создавайте пулл-запросы
Pull request, или запрос на слияние, – это простой способ сообщить вашим товарищам по команде, что функциональность, над которой вы работали, готова. Gitlab дает возможность уведомить об этом заинтересованных лиц.
Главная идея таких запросов – создать точку в git-репозитории, в которой можно обсудить конечный вариант новой фичи.
Есть еще один большой плюс. Когда ваш код мержит кто-то другой, знания и ответственность в отношении конкретной функции разделяются.
Совет 4. Поддерживайте чистоту в git-репозитории
Это простой способ изменить последний коммит. Вместо того, чтобы фиксировать новые изменения отдельно, вы просто объединяете их с предыдущими.
Git rebase
Rebasing (перебазирование или перемещение) позволяет сохранить в вашей feature-ветке ту же историю коммитов, что и в master. Это предотвратит опережение других веток и спасет от ужасных конфликтов слияния.
Внимание!
Совет 5. Версионируйте проект
Семантическое управление версиями – отличная практика, которая позволит навести порядок в вашем git-репозитории.
Выглядит это так: v Major.Minor.Patch, например, v3.5.2.
Вот пример версионированного проекта. В версии 3.3 появилась новая функция Test module. После минорного выпуска было 4 патча: обновления безопасности и конфиденциальности, а также фиксы багов.
Советы для PRO
Именование файлов (core.ignorecase)
По какой-то причине Mac OS по умолчанию не учитывает регистр в файловой системе. Это вызывает много проблем.
Например, в вашем проекте есть два файла: HelloController.php и helloController.php. На Mac OS все работает отлично, вы делаете коммит и отправляете изменения в репозиторий. Но на другой операционной системе появится сообщение об ошибке вида «HelloController.php not found».
Вы можете переименовать файл, но git этого не увидит, ведь по умолчанию он игнорирует регистр.
Эту опцию можно глобально отключить с помощью команды:
Файловый режим (core.fileMode)
Хотя по умолчанию git игнорирует регистр, он отслеживает режимы файлов. Если вы изменили права доступа к файлам, не изменив в них ни строчки, git все же покажет изменения.
Эту опцию можно отключить глобально, выполнив следующую команду:
Grumphp
Grumphp – это инструмент, который пропускает все изменения кода через набор тестов и проверяет, соответствуют ли они настроенным требованиям.
Щеночек счастлив!
Ура, вы спасли щеночка и сохранили чистоту и уют в вашем git-репозитории. Если у вас есть собственные приемы поддержания порядка, поделитесь ими в комментариях.
Как удалить ветку Git
Для организации разработки различных версий программного обеспечения в Git используются ветки. Ветки также очень часто используются для разработки новой функциональности в программе. Если разработкой продукта занимается команда, каждый разработчик может работать над своей частью функциональности в отдельной ветке.
Когда работа будет завершена, получившуюся ветку можно будет совместить с основной перед этим отправив её на проверку другим участникам команды. При таком рабочем процессе со временем накапливается много ненужных веток, которые надо удалять. В этой небольшой статье мы рассмотрим как удалить ветку локально и удаленно git.
Как удалить локальную ветку Git
Прежде чем что-либо удалять необходимо посмотреть какие ветки у вас есть. Для того чтобы посмотреть локальные ветки используйте такую команду в папке с репозиторием:
Команда выведет список локальных веток, а текущая ветка будет выделена зеленым цветом и звездочкой. Для того чтобы удалить ветку необходимо использовать ту же команду branch с опцией -d. Например, для того чтобы удалить ветку feature/somefeature1 выполните такую команду:
Удаление ветки Git завершено, если после этого вы снова проверите список локальных веток, то этой ветки там больше не будет:
А теперь давайте разберемся как выполняется удаление удалённой ветки Git. В данном случае ветка удалилась только локально, но если она была уже отправлена в удалённый репозиторий, то там она всё ещё есть.
Как удалить удалённую ветку Git
Теперь давайте разберемся как удалить ветку из удаленного репозитория git. Прежде чем смотреть ветки необходимо получить список веток и все обновления из добавленных удалённых репозиториев. Для этого выполните:
Для того чтобы посмотреть удалённые ветки необходимо выполнить такую команду в папке с репозиторием git:
Здесь все ветки отмечены красным и перед именем каждой из них выводится имя удалённого источник, в котором есть эта ветка. В данном случае это origin. Для удаления удалённой ветки используется команда push с опцией —delete, например, для той же feature/somefeature1 команда будет выглядеть вот так:
Теперь такой ветки нет в удалённом репозитории:
git push origin :feature/somefeature1
Такая команда тоже будет работать. Если вы хотите удалить все удалённые ветки, которых нет локально, используйте команду:
Выводы
В этой небольшой статье мы рассмотрели как удалить ветку Git, которая размещена удалённо или локально. Как видите, всё это очень просто даже при использовании командной строки. Если вы будете использовать графические клиенты, то всё станет ещё проще.