Обновлено с учетом последующих вопросов в комментариях
.gitignore только работает с неотслеживаемыми файлами.
Если пути отображаются как «измененные» или «не помеченные», это означает, что файлы уже отслежены - они были в индексе и, вероятно, в предыдущих коммитах до того, как вы поместили их в gitignore, или они были принудительно добавлены после того, как вы их поместили в гитиньоре.
Итак, вы пытаетесь игнорировать изменения в отслеживаемых файлах, а это не то, что вы можете сделать в git.
(Для ясности, вы, вероятно, найдете ответы о том, что вы можете использовать различные флаги в индексе, чтобы игнорировать изменения в поэтапных файлах. Это почти всегда приводит к проблемам, потому что это не то, для чего эти флаги.)
Так как же вы можете игнорировать эти файлы? Вы должны сказать Git прекратить их отслеживание. Это легко сделать, но у него могут быть неприятные побочные эффекты.
При условии, что у вас не много долгоживущих веток, простой подход - git rm --cached, чтобы отменить изменения и затем создать новый коммит. Например, если вас беспокоит только очистка главной ветки, вы можете
git checkout master
git rm -r --cached __pycache__ # or whatever other paths
git commit -m "remove unwanted files'
Теперь вы обнаружите, что git status не показывает эти файлы по умолчанию, а git add не добавляет их. НО, если вы делаете что-то, что изменяет файлы, а затем
git checout HEAD^
вернувшись к коммиту, в котором были эти файлы, git будет спокойно обрабатывать изменения, внесенные вами в эти файлы, даже если у него нет копии изменений, из которых можно восстановить. И когда вы впоследствии
git checkout master
они будут полностью удалены с рабочего дерева.
Для *.pyc файлов, возможно, это приемлемо (поскольку Python все равно быстро / тихо восстанавливает их); для других файлов это может быть не так, так что в лучшем случае это подход «используйте с осторожностью».
Альтернатива - которая позволяет избежать вышеуказанных проблем, но сопряжена с собственными затратами - состоит в том, чтобы переписать историю так, чтобы игнорируемые файлы никогда не фиксировались.
Имейте в виду, что, как и при любом переписывании истории, вам придется координировать свои действия с кем-либо, кто разделяет репо
Если вы решите пойти по этому пути, существуют существующие вопросы / ответы, которые документируют процедуру; вы бы искали git-filter-branch with tree-filter или index-filter.