Как удалить файлы из ветки git
Обновлено: 06.07.2024
Я добавил файл с именем "file1.txt" в репозиторий Git. После этого я зафиксировал его, добавил пару каталогов с именем dir1 and dir2 и отправил их в репозиторий Git.
Теперь текущее хранилище имеет "file1.txt" , dir1 и dir2 . Как я могу удалить, "file1.txt" не влияя на других, как dir1 и dir2 ?
git rm это правильный ответ, но помните, что файл все еще будет там в истории. Если вы хотите удалить файл, потому что он содержал конфиденциальную информацию, вам нужно сделать что-то более радикальное. (Изменение истории, особенно для контента, который вы уже добавили, является радикальным действием, и его следует избегать, если это возможно.) Примечание: в GitHub вы теперь можете напрямую удалить файл из веб-интерфейса (даже не клонируя репо). Смотрите мой ответ ниже . @KeithThompson, что это может быть, если я отчаянно хочу это сделать?Если вы хотите удалить файл из репозитория Git и файловой системы , используйте:
Но если вы хотите удалить файл только из репозитория Git и не удалять его из файловой системы, используйте:
И подтолкнуть изменения к удаленному репо
Также удобно: git rm -r directory // Удалить каталог и контент Это не собирается избавляться от этого файла в других коммитах. Обратите внимание, что файл будет удален и локально. Если вы хотите удалить его только из репозитория, выполните: git rm --cached file1.txt Стоит отметить, что если этот файл содержит конфиденциальную информацию (например, учетные данные), вы должны немедленно изменить эти учетные данные . Процитируем GitHub: «После того, как вы отправили коммит в GitHub, вы должны рассматривать любые содержащиеся в нем данные как скомпрометированные. Если вы зафиксировали пароль, измените его! Если вы зафиксировали ключ, сгенерируйте новый».git rm file.txt удаляет файл из репозитория, но также удаляет его из локальной файловой системы .
Чтобы удалить файл из репозитория и не удалять его из локальной файловой системы, используйте:
git rm --cached file.txt
Ниже приведена точная ситуация, когда я использую git для поддержки контроля версий для веб-сайта моего бизнеса, но каталог «mickey» был папкой tmp для обмена частным контентом с разработчиком САПР. Когда он нуждался в ОГРОМНЫХ файлах, я создал личный, несвязанный каталог и установил там ftpd файлы для его загрузки через браузер. Забыв, что я сделал это, я позже выполнил git add -A из базовой директории сайта. Впоследствии git status показали новые файлы, требующие фиксации. Теперь мне нужно было удалить их из отслеживания git и контроля версий .
Ниже приведен пример того, что случилось со мной, когда я случайно удалил .003 файл. К счастью, мне все равно, что случилось с локальной копией .003 , но некоторые другие в настоящее время измененные файлы были обновлениями, которые я только что сделал на веб-сайте, и они были бы грандиозными, если их удалить в локальной файловой системе! «Локальная файловая система» = живой сайт (не очень хорошая практика, но реальность) .
Обновление: Этот ответ получает некоторый трафик, поэтому я подумал, что упомяну другой мой ответ Git, делится парой отличных ресурсов: На этой странице есть рисунок, который помогает демистифицировать Git для меня. Книга "Pro Git" онлайн и мне очень помогает.
Затем вам нужно будет зафиксировать это с помощью чего-то подобного, git commit -m "Just removing file1.txt" а затем, если у вас есть удаленный репозиторий, протолкнуть коммит с чем-то вроде git push origin master .Во-первых, если вы используете git rm , особенно для нескольких файлов, учтите, что любой подстановочный знак будет разрешен оболочкой, а не git командой.
Но, если ваш файл уже находится на GitHub, вы можете (с июля 2013 года) напрямую удалить его из веб-интерфейса!
Просто просмотрите любой файл в вашем хранилище, щелкните значок корзины в верхней части и подтвердите удаление, как и любое другое редактирование через Интернет.
Затем " git pull " в вашем локальном репо, и это также приведет к удалению файла локально.
Что делает этот ответ (окольным) способом удаления файла из git repo?
(Не говоря уже о том, что файл на GitHub находится в «git repo»)
(фиксация будет отражать удаление этого файла):
И просто так, это ушло.
Для получения справки об этих функциях обязательно прочитайте наши справочные статьи по созданию , перемещению , переименованию и удалению файлов.
Примечание. Так как это система контроля версий, Git всегда имеет вашу спину, если вам нужно восстановить файл позже.
Последнее предложение означает, что удаленный файл все еще является частью истории, и вы можете восстановить его достаточно легко (но пока не через веб-интерфейс GitHub):
Чтобы удалить файл из репозитория необходимо сделать следующее:
Во первых, убедиться что Вы на ветке master :
Она будет выделена зелёным и звёздочкой.
Если Вы не на нужной ветке, то переключиться на неё:
Затем необходимо удалить файл. Для этого есть два варианта, можно воспользоваться любым:
можно удалить Git-командой:
либо просто удалить файл с диска (можете просто через проводник) и добавить изменение в индекс следующей командой:
После выполнения одного из двух вариантов файл будет удалён, а изменения в индексе.
.gitignore
Файл .gitignore необходимо добавлять в репозиторий в самом начале. Если вдруг Вы закомитили какие-то файлы, а потом добавили их в .gitignore , то файлы, которые уже под присмотром Git-а не будут удалены, но новые файлы, подподающие под правила из .gitignore , добавляться не будут.
Удалить такой файл можно командой
Внимание! Эта команда именит хеши всех коммитов, в которых был указанный файл, а также всех более поздних коммитов. Будьте аккуратны при последующей отправке изменений на сервер. Возможно, для вас будет полезна опция --force команды push.
Сегодня мы поговорим о удалении и перемещении файлов, находящихся в git репозитории. Я расскажу о том, как обычно выполняют эти операции, что при этом происходит и как лучше их выполнять.
Удаление файлов
Для начала рассмотрим удаление файлов. Я упоминал про эту операцию, когда рассказывал про добавление изменений в репозиторий. В рамках того урока я говорил, что в git репозиторий данные только добавляются. В случае с обычным удалением файла это утверждение верно. Давайте рассмотрим такой пример:
У вас в проекте был файл, который при рефакторинге стал не нужен и вам нужно его удалить. Чаше всего получается так, что вы его сначала удаляете из рабочей директории, а потом уже добавляете в индекс информацию о том, что файл должен быть удален из репозитория. То есть это может быть описано следующими командами:
Результатом выполнения данных команд будет удаление файла из репозитория для коммита, который вы выполните на этом этапе и всех последующих коммитов. Это замечание важно тем, что для предыдущих коммитов этот файл будет находиться в репозитории. Аналогом этих двух команд является команда git rm file.txt . При этом в индекс сразу будет добавлена информация о том, что файл удален и не нужно будет выполнять команду git add .
Также вы можете не выполнять команду git add <pathspec> , а зафиксировать удаление файла непосредственно при выполнении коммита (git commit -a). Но я не советую вам использовать такой вариант (если вы действительно не хотите сделать именно это).
Если команде git rm в pathspec было указано название директории, то вам понадобится указать флаг -r для того, чтобы git рекурсивно удалил файлы, находящиеся в указанной директории.
В случае, если вам необходимо полностью удалить файл из истории git - вам потребуется выполнить совсем не простую команду, которая будет приведена в расшифровке видео:
Она выполнит следующее - для каждого коммита в истории ветки удалит этот файл, если он присутствует. В итоге, у вас перезапишется история всего репозитория с момента появления этого файла. Поэтому, выполнять эту команду нужно только в том случае, если вам это действительно нужно и вы понимаете, что произойдет.
Для выполнения этого действия можно использовать и другие команды. Но мы не будем сейчас их всех рассматривать.
Перемещение файлов
Что касается перемещения файлов - то возможны 3 самых частых случая:
- Файл был перемещен в другую директорию
- Файл был переименован
- Любое из предыдущих действий + при этом файл был отредактирован.
А теперь, давайте абстрагируемся от того, как бы git мог это обработать и опишем эти действия при помощи команд:
Перемещаем файл в новую директорию mv file.txt new_dir/ Теперь git видит, что у него один файл удален ( file.txt ) и один не отслеживается ( new_dir/file.txt ) Зафиксируем удаление файла file.txt git add file.txt Зафиксируем добавление файла new_dir/file.txt под версионный контроль git add new_dir/file.txt
То есть, мы выполнили 3 действия, для того, чтобы зафиксировать перемещение файла в другую директорию (в случае с переименованием файла будет то же самое). git предоставляет 1 команду взамен этим 3-м git mv file.txt new_dir/txt
Как в первом случае, так и во втором, git заметит то, что файл был перемещен (переименован) и будет опираться на эту информацию в будущем. Например, если кто-то отредактирует в будущем файл, который располагался по старому пути, при мерже или ребейзе git определит, что файл был перемещен и, если сможет - то автоматически применит изменения к новому файлу по новому пути. Если не сможет применить изменения автоматически - то в информации о конфликте он скажет, куда был перемещен файл и вы сможете проще разрешить конфликт.
Однако, git не фиксирует факт перемещения файла, если при перемещении он был существенно отредактирован. В таком случаен он зафиксирует удаление первого файла и добавление второго. В случае, описанном выше, это не хорошо, поэтому лучше взять за правило сначала делать коммит, в котором файл перемещается без изменений, а потом делать коммит, который вносит изменения в файл, который располагается по новому пути. Это убережет вас в будущем от проблем с разрешением конфликтов. Или, может быть более неприятная ситуация - если вы будете выполнять ребейз относительно ветки, в которой файл был отредактирован ДО того, как вы его переместили - вы можете и не узнать о том, что файл был отредактирован и, тем самым, просто потеряете изменения, выполненные в нем (или у вас окажется два файла в репозитории - один старый, второй новый).
На этом я закончу знакомство с этими операциями. Не забудьте прочесть справку по командам перед выполнением тестового задания.
Git очень удобная система контроля версий, которая сейчас используется практические повсеместно. Она нужна для того, чтобы команды могли кооперироваться в создании программного продукта и совмещать код написанный разными людьми в одном репозитории.
Когда я учил Git мне говорили, что в работе мне понадобятся всего 3 команды:
Правда, по сути мне немного слукавили, нужен был ещё как минимум:
Однако, на этом все мои теоретические знания по Git заканчивались и достаточно долгое время я пользовался только этими командами, покуда в один момент не начал работать над веб-приложениями, над которыми со мной работали ещё несколько человек.
Там мне объяснили какие команды также нужны в разработке, зачем они используются и как часто они используются. Сегодня я решил поделиться этими командами с вами.
Основная терминология
отслеживаемые файлы - когда файл добавляется в отслеживание Git'а создается специальный кэш, благодаря которому можно будет откатываться к предыдущим версиям файла
неотслеживаемые файлы - когда файл не добавляется в отслеживание Git'а его кэш не хранится в Git'е, а значит откат на предыдущие версии не работает для таких файлов
коммит - специальное название сохранения версии. Таким образом мы называем все изменения в файлах одним именем и сможем перемещаться между коммитами
откат - переход на предыдущий коммит и отмена изменений с текущего коммита до того, на который мы хотим вернуться
пуш - отправка изменений на удаленный репозиторий (в Github, Gitlab, BitBucket)
фетч - скачивание изменений из репозитория
ветка - ветки создают, когда нужно несколько активных вариантов разработки. В основном их используют для того, чтобы быстро разработать некоторый функционал, а потом слить ветки в одну
мердж - слитие веток в одну
Работа с Git
Прежде всего нам понадобятся команды для работы с файлами. Знать add конечно хорошо, но нужно иногда и удалять что-то из кэшируемых файлов или изменять поведение Git для определенных файлов. Сегодня я разберу некоторые команды, которые позволят вам манипулировать с файлами, ветками, коммитами в Git.
init
Данная команда инициализирует систему контроля версий. Для того чтобы создать новый репозиторий достаточно просто ввести:
clone
Данная команда нужна для того, чтобы клонировать репозиторий из облака. Можно клонировать репозитории из Github, Gitlab, BitBucket и других сервисов. Для того чтобы склонировать репозиторий нужно ввести:
add
Данная команда понадобится вам, когда вам нужно добавить файл для кэширования. Давайте разберёмся как это работает:
Вы изменяете файлы, можете изменять достаточно много файлов, задачи изменения которых вообще никак не связаны
Вы решаете "закоммитить" ваши файлы (сделать сохранение версии, для того чтобы Git запомнил все ваши изменения в файлах и как-то назвал их, для этого есть отдельная команда git commit )
Вы также можете добавить файлы, которые ранее не отслеживались, для того чтобы Git занёс их в свою систему хранения версий и вы могли откатываться на какую-то из версий файла
Обычно с самого начала все разработчики делают коммит (сохранение версии) с названием init , занося все файлы в систему отслеживания. Делается это с помощью простой последовательности команд:
Проделав данный алгоритм, состоящий из двух команд вы занесёте все файлы из вашего проекта в систему контроля версий Git.
Но, что если вам не хочется вносить все файлы? Тогда вы может использовать следующий синтаксис:
Так, хорошо, но что если нам нужно занести весь проект в систему отслеживания, однако есть пару директорий, которые мы не хотим заносить (например, node_modules или out )? Для этого мы можем создать файл .gitignore , в котором будут прописаны пути до файлов и директорий, которые Git должен игнорировать:
В данном случае Git будет игнорировать директорию node_modules , out и файл one_file.tsx
Также мы можем сделать так, чтобы Git искал некоторые названия в дочерних директориях и игнорировал их:
Данный пример говорит о том, что Git будет игнорировать директорию node_modules , которая будет находится в любой дочерней директории (включая корневую).
Больше о .gitignore можно прочитать здесь
А что если я хочу обновить уже закэшированные файлы, мне что теперь их писать по одному? Конечно же нет. Для этого существует специальный флаг -u (сокращение от --update ), который позволяет закэшировать только те файлы, которые уже отслеживаются:
rm
Данная команда поможет, когда нам нужно избавиться от файла, она подобно команде rm удаляет файл из файловой системы и кэша Git, позволяя нам быстро избавиться от файла.
Данный пример удалит файл file.txt из кэша и файловой системы.
Но, что если мы добавили файл, который нам более не нужен в кэше, но нужен в файловой системе? Тогда мы можем воспользоваться следующей командой:
Данная команда удалит файл из "кэша", но что это значит? Допустим, что мы "закоммитили" (сохранили версию, об этом поговорим вот уже совсем скоро) наш файл, а теперь хотим, чтобы Git считал что мы его удалили, а сами просто оставили его на диске. Для этого и нужна команда выше. Она просто говорит Git: "Слушай, а давай ты просто удалишь этот файл из кэша и не будешь его показывать в репозитории, а я оставлю копию у себя на ПК, ок?"
Таким образом мы можем работать с данным файлом и Git не будет знать что именно в нём мы изменяем, а затем просто можем опять добавить его. Файл будет висеть в состоянии "untracked" (не отслеживается) до тех пор, покуда мы его опять не добавим.
commit
Думаю, что стоит поговорить об этом уже сейчас, ибо позже без данной команды уже никуда. Данная команда буквально сохраняет версию, в которой указывается что именно в файлах мы изменили.
Обычно разработчики сохраняют версию программы с помощью данной команды:
В данном случае мы просто скажем, чтобы Git сохранил все изменения, которые мы сделали в файлах, которые отслеживаются. Файлы, которые не отслеживаются просто не попадают в версию, а также их изменения никак нельзя отследить.
Для того чтобы отменить последний коммит (отменить не изменения, а именно просто разкоммитить изменения) и совместить его с текущими изменениями используйте команду:
show
Данная команда нужна для того, чтобы быстро показать что было сделано за предыдущие коммит:
Выведутся изменения следующим образом:
status
Если до этого момента вы не знали как проверить какой файл кэшируется, какой не отслеживается, а какие файлы и вовсе только что были удалены из кэша, то спешу вас обрадовать, у вас теперь есть команда git status , которая даёт возможность посмотреть что именно происходит с вашими файлами:
Если вы хотите узнать более подробно о том, что же именно случилось с вашими файлами, то можете добавить ключ -v (сокращение от --verbose - внимательно):
Если же вам наоборот хочется увидеть бриф по информации, то добавьте флаг -s (сокращение от --short ):
log
До этого момента мы могли только посмотреть что творилось в предыдущем коммите, однако с помощью git log мы можем посмотреть историю наших коммитов:
Если же вы хотите красиво вывести все ваши коммиты в столбик, то используйте данную команду:
В данной команде мы описываем что хотим просматривать коммиты и их названия в одну строку, хотим чтобы коммиты сокращали свой ID, а также чтобы всё это красиво было разбито по списку
diff
С помощью данной команды мы можем посмотреть на изменения между коммитами. Эта комманда является одной из самых мощных в Git, вам стоит обратить на неё внимание:
Так называемые "ID-коммита" можно взять и вышеприведенной git log
Также, можно посмотреть что было изменено с момента последнего коммита (что изменено и попало в кэш) с помощью флага --cached :
Если вы хотите посмотреть историю изменений в файлах в определенном коммите, то используйте следующую команду:
Если вы хотите посмотреть на статистику, то вы всегда можете использовать флаг --stat :
Если вы хотите посмотреть на изменения только тех файлов, которые добавлены для отслеживания, то нужно ввести следующую команду:
branch
В Git есть ветки для разделения версий. Если коммит нужен для того, чтобы сделать snapshot (слепок изменений) файлов, то ветки нужны для того, чтобы эти snapshot'ы разделять. У вас может быть ветка
любое другое название
Для того чтобы перечислить все ветки с помощью Git нужно ввести следующую команду:
Для того чтобы создать новую ветку нужно ввести:
checkout
Checkout используют для того, чтобы переходить между ветками. Для того чтобы перейти на другую ветку достаточно просто написать:
Для того чтобы создать ветку и сразу же перейти на неё достаточно ввести:
merge
Соединение веток не являются сложной темой. Для того чтобы слить текущую ветку с другой нужно ввести:
push
Для того чтобы закинуть изменения на сервер нужна комнда push , которая позволит нам закинуть текущую ветку на удаленный репозиторий:
В завершение
Здесь мы чуть более глубже познакомились с основами Git, поняли как работать с ветками, как их мерджить, как коммитить файлы, смотреть изменения, а также как показывать последние коммиты.
Если вы хотите больше узнать о веб-разработке, а также о линуксе, то милости прошу в мой блог на телеграм.
Надеюсь данная статья помогла вам чуть лучше узнать Git. Хорошего дня и продуктивной недели!
Читайте также: