39

Читаю книгу Test-Driven Development with Python, во второй главе описывается создание git-репозитория. Я следую всем инструкциям, но мой файл .gitignore не игнорирует записанное в нём. В чём проблема?

pic

Nick Volynkin
  • 34,094
Dmitriy Kuzminov
  • 545
  • 5
    Вероятно вы добавили в .gitignore файлы, которые уже попали в ваш репозиторий попробуйте git rm --cached, как там написано – Darth Jun 28 '15 at 11:25
  • @Darth, оформите, пожалуйста, ваш комментарий в виде ответа. – aleksandr barakin Jun 28 '15 at 11:50
  • 2
    А покажите содержимое файла .gitignore, а то есть подозрение, что там db.sqlite3 может быть записан не на отдельной строке, а где-то после другой сигнатуры.

    Судя по скриншоту, не похоже, что файлы уже попали в репозиторий, поскольку git status отмечает их как новые.

     – Jenyay Jun 28 '15 at 13:37
  • Присоединюсь к догадке @Darth – etki Jun 30 '15 at 18:55
  • Дмитрий, как там ваш репозиторий? Получилось решить задачу? – Nick Volynkin Jul 01 '15 at 18:40
  • Да, удалил всё и по новой создал. Со второй попытки все хорошо, спасибо. – Dmitriy Kuzminov Jul 02 '15 at 03:14

4 Answers4

69

Подозреваю, что вы добавили файлы в индекс раньше, чем начали игнорировать. То есть до той git add ., который на скриншоте, была еще одна такая команда. Чтобы узнать точно, не хватает git status перед добавлением.

Если файл уже был добавлен, то изменение в .gitignore не вызывает удаления из текущего индекса (что логично и безопасно).

Если файлы только добавлены, но еще не включены в коммит

В данном конкретном случае именно так и есть. При этом достаточно удалить их из индекса. Данная команда возвращает индекс к HEAD, то есть состоянию последнего коммита.

git reset <file-name>

Вы можете заметить, что сам Git предлагает использовать другую команду: 

git rm --cached <file-name>

В данном случае эти команды эквивалентны. Такое дублирование появилось в результате эволюционного развития функционала Git. Это в том числе отражено в документации и в сообщениях Git: где-то рекомендуется reset, где-то rm --cached.

Если игнорируемые файлы уже есть в последнем коммите

Возможна и такая ситуация, на всякий случай я опишу и ее. Здесь reset не сработает, нужен rm. Аргумент --cached заставляет Git удалить файл из индекса, но не трогать рабочую область. То есть он буквально индексирует удаление файла, хотя этого удаления не было. Если сделать это с файлом, который не игнорируется, то после коммита он будет в категории неотслеживаемых (untracked).

git rm --cached <file-name>

Если нужно убрать целую игнорируемую папку, добавляем ключ -r:

git rm -r --cached <path>

Эта удобная команда применяет rm ко всем файлам, указанным в .gitignore:

git rm --cached `git ls-files -i --exclude-from=.gitignore`

Вариант того же для windows powershell:

foreach ($i in iex 'git ls-files -i --exclude-from=.gitignore') { git rm --cached $i }

Теперь результат команды git rm нужно зафиксировать коммитом.

git commit -m'removed gitignored files'
Дух сообщества
  • 1
Nick Volynkin
  • 34,094
14

Команда

git rm --cached `git ls-files -i --exclude-from=.gitignore`

имеет проблемы с пробелами в названиях.

Самый простой путь - удалить из кэша ВСЕ файлы, и добавить заново с учетом gitignore. на все про все 2 команды.

git rm -rf --cached .
git add .

потом закоммитить:

git commit -m "fix gitignore"
Shelby Cobra
  • 141
  • Что за проблемы с пробелами команды которая в начале вашей записи? – White Raven Jun 16 '21 at 12:35
0

На ваш вопрос ответ простой. Наименование файлов и директорий которые игнорируются гитом должны быть записаны в .gitignore без кавычек ("). Пример в книге добавляет в .gitignore имена файлов обрамленные кавычками, в результате гит не может их идентифицировать. У берите кавычки и все будет работать.

Konstantin Yudin
  • 1
0
git filter-branch --force (чтобы не удалился каталог с жесткого диска)

git filter-branch --tree-filter "rm -rf PATH" HEAD

где PATH - путь к файлу/папке

https://toster.ru/q/176843

https://help.github.com/en/articles/removing-sensitive-data-from-a-repository

Suvitruf - Andrei Apanasik
  • 32,302
Oleg
  • 111