Git убрать файл из под контроля
Обновлено: 05.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):
Итак, у вас имеется настоящий Git-репозиторий и рабочая копия файлов для некоторого проекта. Вам нужно делать некоторые изменения и фиксировать “снимки” состояния (snapshots) этих изменений в вашем репозитории каждый раз, когда проект достигает состояния, которое вам хотелось бы сохранить.
Запомните, каждый файл в вашем рабочем каталоге может находиться в одном из двух состояний: под версионным контролем (отслеживаемые) и нет (неотслеживаемые). Отслеживаемые файлы — это те файлы, которые были в последнем слепке состояния проекта (snapshot); они могут быть неизменёнными, изменёнными или подготовленными к коммиту (staged). Неотслеживаемые файлы — это всё остальное, любые файлы в вашем рабочем каталоге, которые не входили в ваш последний слепок состояния и не подготовлены к коммиту. Когда вы впервые клонируете репозиторий, все файлы будут отслеживаемыми и неизменёнными, потому что вы только взяли их из хранилища (checked them out) и ничего пока не редактировали.
Как только вы отредактируете файлы, Git будет рассматривать их как изменённые, т.к. вы изменили их с момента последнего коммита. Вы индексируете (stage) эти изменения и затем фиксируете все индексированные изменения, а затем цикл повторяется. Этот жизненный цикл изображён на рисунке 2-1.
Рисунок 2-1. Жизненный цикл состояний файлов.
Определение состояния файлов
Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда git status . Если вы выполните эту команду сразу после клонирования, вы увидите что-то вроде этого:
Это означает, что у вас чистый рабочий каталог, другими словами — в нём нет отслеживаемых изменённых файлов. Git также не обнаружил неотслеживаемых файлов, в противном случае они бы были перечислены здесь. И наконец, команда сообщает вам на какой ветке (branch) вы сейчас находитесь. Пока что это всегда ветка master — это ветка по умолчанию; в этой главе это не важно. В следующей главе будет подробно рассказано про ветки и ссылки.
Предположим, вы добавили в свой проект новый файл, простой файл README. Если этого файла раньше не было, и вы выполните git status , вы увидите свой неотслеживаемый файл вот так:
Понять, что новый файл README неотслеживаемый можно по тому, что он находится в секции "Untracked files" в выводе команды status . Статус "неотслеживаемый файл", по сути, означает, что Git видит файл, отсутствующий в предыдущем снимке состояния (коммите); Git не станет добавлять его в ваши коммиты, пока вы его явно об этом не попросите. Это предохранит вас от случайного добавления в репозиторий сгенерированных бинарных файлов или каких-либо других, которые вы и не думали добавлять. Мы хотели добавить README, так давайте сделаем это.
Отслеживание новых файлов
Для того чтобы начать отслеживать (добавить под версионный контроль) новый файл, используется команда git add . Чтобы начать отслеживание файла README, вы можете выполнить следующее:
Если вы снова выполните команду status , то увидите, что файл README теперь отслеживаемый и индексированный:
Вы можете видеть, что файл проиндексирован по тому, что он находится в секции “Changes to be committed”. Если вы выполните коммит в этот момент, то версия файла, существовавшая на момент выполнения вами команды git add , будет добавлена в историю снимков состояния. Как вы помните, когда вы ранее выполнили git init , вы затем выполнили git add (файлы) — это было сделано для того, чтобы добавить файлы в вашем каталоге под версионный контроль. Команда git add принимает параметром путь к файлу или каталогу, если это каталог, команда рекурсивно добавляет (индексирует) все файлы в данном каталоге.
Индексация изменённых файлов
Давайте модифицируем файл, уже находящийся под версионным контролем. Если вы измените отслеживаемый файл benchmarks.rb и после этого снова выполните команду status , то результат будет примерно следующим:
Файл benchmarks.rb находится в секции “Changes not staged for commit” — это означает, что отслеживаемый файл был изменён в рабочем каталоге, но пока не проиндексирован. Чтобы проиндексировать его, необходимо выполнить команду git add (это многофункциональная команда, она используется для добавления под версионный контроль новых файлов, для индексации изменений, а также для других целей, например для указания файлов с исправленным конфликтом слияния). Выполним git add , чтобы проиндексировать benchmarks.rb, а затем снова выполним git status :
Теперь оба файла проиндексированы и войдут в следующий коммит. В этот момент вы, предположим, вспомнили одно небольшое изменение, которое вы хотите сделать в benchmarks.rb до фиксации. Вы открываете файл, вносите и сохраняете необходимые изменения и вроде бы готовы к коммиту. Но давайте-ка ещё раз выполним git status :
Что за чёрт? Теперь benchmarks.rb отображается как проиндексированный и непроиндексированный одновременно. Как такое возможно? Такая ситуация наглядно демонстрирует, что Git индексирует файл в точности в том состоянии, в котором он находился, когда вы выполнили команду git add . Если вы выполните коммит сейчас, то файл benchmarks.rb попадёт в коммит в том состоянии, в котором он находился, когда вы последний раз выполняли команду git add , а не в том, в котором он находится в вашем рабочем каталоге в момент выполнения git commit . Если вы изменили файл после выполнения git add , вам придётся снова выполнить git add , чтобы проиндексировать последнюю версию файла:
Игнорирование файлов
), которая используется во многих текстовых редакторах, например Emacs, для обозначения временных файлов. Вы можете также включить каталоги log, tmp или pid; автоматически создаваемую документацию; и т.д. и т.п. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.
К шаблонам в файле .gitignore применяются следующие правила:
Glob-шаблоны представляют собой упрощённые регулярные выражения используемые командными интерпретаторами. Символ * соответствует 0 или более символам; последовательность [abc] — любому символу из указанных в скобках (в данном примере a, b или c); знак вопроса ( ? ) соответствует одному символу; 2 соответствует любому символу из интервала (в данном случае от 0 до 9).
Шаблон **/ доступен в Git, начиная с версии 1.8.2.
Просмотр индексированных и неиндексированных изменений
Допустим, вы снова изменили и проиндексировали файл README, а затем изменили файл benchmarks.rb без индексирования. Если вы выполните команду status , вы опять увидите что-то вроде:
Чтобы увидеть, что же вы изменили, но пока не проиндексировали, наберите git diff без аргументов:
Эта команда сравнивает содержимое вашего рабочего каталога с содержимым индекса. Результат показывает ещё не проиндексированные изменения.
Важно отметить, что git diff сама по себе не показывает все изменения сделанные с последнего коммита — только те, что ещё не проиндексированы. Такое поведение может сбивать с толку, так как если вы проиндексируете все свои изменения, то git diff ничего не вернёт.
Другой пример: вы проиндексировали файл benchmarks.rb и затем изменили его, вы можете использовать git diff для просмотра как индексированных изменений в этом файле, так и тех, что пока не проиндексированы:
Теперь вы можете используя git diff посмотреть непроиндексированные изменения
Фиксация изменений
Теперь, когда ваш индекс настроен так, как вам и хотелось, вы можете зафиксировать свои изменения. Запомните, всё, что до сих пор не проиндексировано — любые файлы, созданные или изменённые вами, и для которых вы не выполнили git add после момента редактирования — не войдут в этот коммит. Они останутся изменёнными файлами на вашем диске. В нашем случае, когда вы в последний раз выполняли git status , вы видели что всё проиндексировано, и вот, вы готовы к коммиту. Простейший способ зафиксировать изменения — это набрать git commit :
Есть и другой способ — вы можете набрать свой комментарий к коммиту в командной строке вместе с командой commit , указав его после параметра -m, как в следующем примере:
Итак, вы создали свой первый коммит! Вы можете видеть, что коммит вывел вам немного информации о себе: на какую ветку вы выполнили коммит (master), какая контрольная сумма SHA-1 у этого коммита ( 463dc4f ), сколько файлов было изменено, а также статистику по добавленным/удалённым строкам в этом коммите.
Запомните, что коммит сохраняет снимок состояния вашего индекса. Всё, что вы не проиндексировали, так и торчит в рабочем каталоге как изменённое; вы можете сделать ещё один коммит, чтобы добавить эти изменения в репозиторий. Каждый раз, когда вы делаете коммит, вы сохраняете снимок состояния вашего проекта, который позже вы можете восстановить или с которым можно сравнить текущее состояние.
Игнорирование индексации
Несмотря на то, что индекс может быть удивительно полезным для создания коммитов именно такими, как вам и хотелось, он временами несколько сложнее, чем вам нужно в процессе работы. Если у вас есть желание пропустить этап индексирования, Git предоставляет простой способ. Добавление параметра -a в команду git commit заставляет Git автоматически индексировать каждый уже отслеживаемый на момент коммита файл, позволяя вам обойтись без git add :
Обратите внимание на то, что в данном случае перед коммитом вам не нужно выполнять git add для файла benchmarks.rb.
Удаление файлов
Если вы просто удалите файл из своего рабочего каталога, он будет показан в секции “Changes not staged for commit” (“Изменённые но не обновлённые” — читай не проиндексированные) вывода команды git status :
Затем, если вы выполните команду git rm , удаление файла попадёт в индекс:
В команду git rm можно передавать файлы, каталоги или glob-шаблоны. Это означает, что вы можете вытворять что-то вроде:
Обратите внимание на обратный слэш ( ) перед * . Он необходим из-за того, что Git использует свой собственный обработчик имён файлов вдобавок к обработчику вашего командного интерпретатора. Эта команда удаляет все файлы, которые имеют расширение .log в каталоге log/ . Или же вы можете сделать вот так:
Эта команда удаляет все файлы, чьи имена заканчиваются на
Перемещение файлов
и это отлично сработает. На самом деле, если вы выполните что-то вроде этого и посмотрите на статус, вы увидите, что Git считает, что произошло переименование файла:
Однако, это эквивалентно выполнению следующих команд:
Git неявно определяет, что произошло переименование, поэтому неважно, переименуете вы файл так или используя команду mv . Единственное отличие состоит лишь в том, что mv — это одна команда вместо трёх — это функция для удобства. Важнее другое — вы можете использовать любой удобный способ, чтобы переименовать файл, и затем воспользоваться add/rm перед коммитом.
Если внести файл в .gitignore, то он не будет отслеживаться гитом лишь в том случае, если этого файла нет в удаленном репозитории.
Update: Если конфиг изменили
Если всё же кто-то изменил структуру файла конфига, то git не даст сделать pull, т.к. все-равно будет считать, что файл конфига с нашими паролями отличается от того, что прийдет с командой pull.
Чтобы все-таки получить новые изменения, но и свои пароли сохранить в конфиге нужно сделать следующее:
1. Сохранить текущие конфиги (с нашими локальными паролями) в отдельную папку например.
3. На данном шаге команда git status покажет, что файл application/config/database.php был изменен, но еще не проиндексирован. Именно эти изменения и мешают нам забрать командой git pull новые изменения. Учитывая, что на шаге 1 мы сохранили наши конфиги в отдельную папку — мы можем сейчас отменить эти изменения.
git checkout application/config/database.php
4. Сейчас git status покажет, что изменений нет ( nothing to commit, working tree clean ). Забираем новые изменения:
git pull
5. Опционально: Если мы привыкли работать в отдельной ветке (не в master), то переходим в эту ветку (например: dev-branch) для последующей работы:
git checkout dev-branch
и вливаем в ветку dev-branch новые изменения из ветки master (куда мы их уже получили командой git pull ):
git merge master
6. Изменяем теперь наши обновленные конфиги, возвращая туда наши локальные пароли и все то, что мы желаем там видеть, но не хотим это хранить в репозитории (для этого мы сохранили все в шаге 1). После чего команда git status естественно покажет, что конфиги изменены, но не проиндексированы.
После чего git status покажет, что все чисто ( nothing to commit, working tree clean ) и мы сможем снова работать, делать коммиты и переключаться между ветками.
P.S. Разумеется автор не рекомендует хранить конфиги с паролями в репозитории. Это лишь наглядный пример.
Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.
мне нужно исключить папку (имя загрузки) из отслеживания. Я пытался бежать
и после этого я добавил путь .gitignore
но когда я побежал git status они отображаются как удаленные. Если я попытаюсь зафиксировать изменения, файлы будут удалены, а не только удалены из отслеживания.
что я делаю не так?
Я также пробовал
но это, кажется, отследить только файлы. Но мне нужно удалить целый папка (включая подпапки) из отслеживания.
я столкнулся с этим вопросом, когда гуглил для "Git удалить папку из отслеживания". Вопрос операции привел меня к ответу. Я резюмирую его здесь для будущих поколений.
вопрос
Как удалить папку из репозитория git, не удаляя ее с локального компьютера (т. е. среды разработки)?
ответ
Шаг 1. Добавьте путь к папке в корневой каталог РЕПО .gitignore файл.
Шаг 2. Удалите папку из локального отслеживания git, но сохраните ее на диске.
Шаг 3. Толкать свои изменения в Git РЕПО.
В рамках данного урока рассмотрим вопросы, касающиеся добавления, удаления и переименования файлов в git репозитории.
Добавление файлов в git репозиторий
Создайте в каталоге файл README.md любым удобным для вас способом, мы сделаем это с помощью команды touch .
Теперь проверим состояние отслеживаемой директории.
Как вы можете видеть: в рабочей директории есть один неотслеживаемый файл README.md . Git нам подсказывает, что нужно сделать для того, чтобы начать отслеживать изменения в файле README.md : необходимо выполнить команду git add , сделаем это.
Посмотрим ещё раз на состояние.
Видно, что информация о появлении нового файла попала в stage . Для того чтобы это изменение зафиксировалось в репозитории необходимо выполнить команду git commit .
Теперь в рабочей директории и в stage нет объектов, информацию об изменении которых необходимо внести в репозиторий.
В репозиторий был сделан один коммит.
Удаление файлов из git репозитория и из stage
Удаление файла из stage
Вначале разберемся со stage . Создадим ещё один файл.
Внесем изменения в README.md .
Информацию об этом также отправим в stage .
Посмотрим на состояние stage .
Теперь посмотрим на состояние рабочей директории и stage .
Удаление файлов из git репозитория
Удалим файл main.c из рабочей директории.
Уведомим об этом систему git .
Теперь в репозитории остался только один файл README.md .
Удалим файл из репозитория.
Файла main.c больше нет в репозитории.
Его также нет и в рабочем каталоге.
Удалите файл README.md из репозитория самостоятельно.
Переименование файлов в git репозитории
Первый способ. Создадим файл test_main_file.c и добавим его в репозиторий.
Содержимое репозитория после этого будет выглядеть так.
Переименуем его на test_main.c .
Сделаем это в рабочей директории.
Теперь отправим изменение в репозиторий.
В репозитории и в рабочей директории будет находится только файл test_main.c .
Второй способ.
В рамках второго способа рассмотрим работу с командой git mv . Переименуем файл test_main.c в main.c . Текущее содержимое репозитория и рабочего каталога.
Переименуем файл test_main.c на main.c средствами git .
Имя файла изменилось как в репозитории так и в рабочем каталоге.
Это краткая инструкция по работе с git, я здесь собрал список команд, чтобы не забывать, да и чтобы была возможность их быстро найти.
Все команды будут постоянно обновляться. Если вы найдете ошибки, пишите, буду исправлять.
Инициалиализация git
git init
Добавление всех файлов в git для отслеживания:
git add .
Проверка статуса изменения файлов в git
git status
Просмотр истории коммитов в git
git log
Публиция файлов на удаленном сервере:
git push -u repos branch [repos - название репозитория, branch - это ветка]
Получение изменений на удаленном сервере
git fetch repos [repos - имя удал. сервера]
Удалние файлов из отслеживаемых в git:
git rm file_name [file_name - название файла]
Удаление файлов из индекса git
git rm --cached path_to_file [path_to_file - путь к файлу или папке]
Получение информации об удаленном сервере
git remote show server_name [server_name - имя удал. сервера]
Получение всех удаленных серверов git(имеется ввиду серверов, с которыми вы работаете.)
git remote
git remote -v [-v - доп. параметр, показывает ссылки на удаленный сервер]
Переименовать удаленный реп.
git remote rename old_name new_name [old_name - старое название; new_name - новое название]
Удалить удаленный реп.
git remote rm rep_name [rep_name - название реп. который следует удалить]
Создание новой ветки в git
git branch branch_name [branch_name - имя ветки]
Переход на нужную ветку в git
git checkout branch_name [branch_name - имя ветки]
Создание новой ветки в git и моментальное переключение на нее
git checkout -b branch_name [branch_name - имя ветки]
Переименовать локальную ветку (вот тут более расширенная статья по переименованию ветки в GIT)
git branch -m [branch_name - имя ветки]
Слияние(merge) веток в git
git merge branch_name [branch_name - имя ветки]
Удаление ветки в git
git branch -d branch_name [branch_name - имя ветки]
Отмена индексации файла в git
git reset HEAD file_name [file_name - название файла]
Отмена изменений файла в git
git checkout file_name [file_name - название файла]
Читайте также: