Чому Git не ігнорує вказаний файл?

Я додав наступний рядок до .gitignore:

sites/default/settings.php

але коли я git statusнабираю, він показує файл як нестандартний файл.

В чому проблема? Всі інші зразки працюють добре.

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

Якщо це не працює, можливо, Git вже відстежує ваш файл. Ви можете підтвердити це на виході git status. Якщо файл не вказаний у розділі «Неназвані файли» , він вже відстежується Git, і він буде ігнорувати правило з .gitignoreфайлу.

Причина ігнорувати файли в Git полягає в тому, що вони не будуть додані до сховища. Якщо ви раніше додали файл, який ви хочете проігнорувати, він буде відслідковуватися Git, і правила ігнорування, відповідні йому, будуть пропущені. Git робить це, оскільки файл уже є частиною сховища.

Для того, щоб насправді ігнорувати файл, вам потрібно відстежити його та видалити з сховища. Це можна зробити за допомогою git rm --cached sites/default/settings.php. Це видаляє файл із сховища, не видаляючи його фізично (саме це і --cachedробиться). Після внесення цієї зміни файл буде вилучений із сховища, і ігнорування його має працювати належним чином.

Я стикаюся з цим, це старе питання, але я хочу, щоб цей файл відслідковувався, але не відслідковувався в певних робочих копіях, щоб це зробити, ви можете запустити

git update-index --assume-unchanged sites/default/settings.php

.gitignore буде ігнорувати лише ті файли, які ви ще не додали до вашого сховища.

Якщо ви зробили git add ., а файл додали до індексу, .gitignore не допоможе вам. Вам потрібно буде зробити git rm sites/default/settings.phpйого, щоб видалити його, і тоді воно буде проігноровано.

Будь ласка, використовуйте цю команду

git rm -rf --cached .
git add .

Іноді .gitignore файли не працюють, навіть якщо вони правильні. Причина, через яку Git ігнорує файли, полягає в тому, що вони не додаються до сховища. Якщо ви додали файл, який ви хочете ігнорувати раніше, його відстежуватиме Git, і будь-які правила пропуску відповідності будуть пропущені. Git робить це тому, що файл вже є частиною сховища.

У мене була така ж проблема. Файли, визначені .gitingoreтам, де вказано, як незапущені файли під час запуску git status.

Причина полягала в тому, що .gitignoreфайл зберігався в UTF-16LEкодуванні, а не в UTF8кодуванні.

Після зміни кодування .gitignoreфайлу UTF8він працював на мене.

Що я зробив, щоб успішно ігнорувати файл settings.php :

1. git rm - кешовані сайти / за замовчуванням / settings.php
2. покластися (до цього не працювало)
3. вручну видалено сайти / за замовчуванням / settings.php (це зробило трюк)
4. git add.
5. здійснити (ігнорується успішно)

Я думаю, якщо на Git є скоєний файл, то ігнорування не працює так, як очікувалося. Просто видаліть файл і виконайте фіксацію. Згодом вона проігнорує.

Є випадки, наприклад, файли конфігурації програми, які я хочу відслідковувати в git (тому .gitignore не працюватиме), але які мені потрібно змінити для локальних налаштувань. Я не хочу, щоб git керував цими файлами або показував їх як змінені. Для цього я використовую skip-worktree:

git update-index --skip-worktree path/to/file

Ви можете підтвердити пропуск файлів, перерахувавши файли і перевіривши рядки, починаючи з S для пропущених

git ls-files -v | grep ^S

Якщо в майбутньому ви знову хочете, щоб git керував файлом локально, просто запустіть:

 git update-index --no-skip-worktree path/to/file

Мескаліто вище мав чудову відповідь, що привело мене до правильного шляху, але

git update-index - файл без змін / до / ignore.php

Має договір з git тим, у якому: користувач обіцяє не змінювати файл і дозволяє Git припускати, що файл робочого дерева відповідає тому, що записано в індексі.

Однак я змінюю вміст файлів, тому в моєму випадку --skip-worktree - кращий варіант.

Веб-сайт Toshiharu Nishina дав чудове пояснення пропуску робочого дерева та припустимо-незмінного: ігноруйте файли, які вже керуються за допомогою Git локально

Ще одна можлива причина - кілька примірників git-клієнтів, які працюють одночасно . Наприклад, "git shell" + "GitHub Desktop" тощо.

Це сталося зі мною, я використовував "GitHub Desktop" в якості основного клієнта, і він ігнорував деякі нові налаштування .gitignore: commit after commit:

1. Ви щось вчиняєте.
2. Далі, зробіть фіксацію: вона ігнорує налаштування .gitignore. Комутація включає в себе безліч темп-файлів, згаданих у .gitignore.
3. Очистити кеш-пам'ять git; перевірити, чи є .gitignore UTF8; видалити файли -> фіксувати -> перемістити файли назад; пропустити 1 фіксацію - нічого не допомогло.

Причина : редактор коду Visual Studio працював у фоновому режимі з тим же відкритим сховищем. Код VS має вбудований контроль git, і це створює деякі конфлікти.

Рішення : двічі перевірити кілька прихованих клієнтів git та використовувати лише один клієнт git одночасно, особливо під час очищення кеш-пам'яті git.

Переконайтесь, що .gitignore не має розширення !! Це не може бути .gitignore.txt, у Windows просто назвіть файл .gitignore. і воно спрацює.

Я просто спробував це з git 1.7.3.1 і надав структуру на зразок:

repo/.git/
repo/.gitignore
repo/sites/default/settings.php

де repoтаким чином є "корінь", згаданий вище (я би назвав його коренем вашого робочого дерева), і .gitignoreмістить лише sites/default/settings.php, що ігнорування працює для мене (і не має значення .gitignore, додається він до репо або ні). Чи відповідає це макету репо? Якщо ні, то чим відрізняється?

На всякий випадок, якщо хтось у майбутньому матиме ту саму проблему, що і я:

Якщо ви використовуєте

*
!/**/
!*.*

трюк для видалення бінарних файлів без розширення, переконайтесь, що ВСІ інші рядки gitignore розташовані нижче Git буде читати з .gitignore зверху, тому, хоч у мене в gitignore був 'test.go', він був першим у файлі, а після цього став "ungnored"

!*.*

Я спробував більшість команд вище на терміналі коду VS, і у мене виникли помилки:

fatal: pathspec '[dir]/[file]' did not match any files

Я відкрив проект на GitHub Desktop і проігнорував звідти, і він спрацював.