Как сделать чтобы gitignore не пушился

Добавил пользователь Дмитрий К.
Обновлено: 19.09.2024

Мы конечно могли бы вручную добавлять нужные файлы в репозиторий, например так:

Однако это было бы очень трудоемко. Гораздо проще использовать команду:

Которая добавит все файлы в каталоге проекта.

Но что если нам не нужны абсолютно все файлы, а есть файлы например в каталоге /cache или /images или /runtime проекта, которые генерируются в процессе работы. Они не должны быть добавлены в репозиторий.

Тут нам и нужен .gitignore. Вам нужно его самим создать и разместить в корне проекта либо нужной подпапке.

Где должен находиться этот файл

Файл может находиться в корне проекта или любом подкаталоге.

Либо можно задать глобальный файл gitignore, таким образом:

Таким образом вы сможете записать в глобальный файл ~/.gitignore_global настройки, общие для всех ваших проектов. В нем могут храниться например файлы для игнорирования, которые специфичны для вашей IDE, и по этому не логично добавлять их в репозиторий. Однако файлы, которые специфичны для конкретного проекта, обязательно нужно добавлять в .gitignore самого проекта.

Примеры содержимого .gitignore файла

Подробнее о шаблонах игнорирования

Шаблон	Примеры соответствия	Пояснение*
**/logs	logs/debug.log logs/monday/foo.bar build/logs/debug.log	Добавьте в начало шаблона две звездочки, чтобы сопоставлять каталоги в любом месте репозитория.
**/logs/debug.log	logs/debug.log build/logs/debug.log но не logs/build/debug.log	Две звездочки можно также использовать для сопоставления файлов на основе их имени и имени родительского каталога.
*.log	debug.log foo.log .log logs/debug.log	Одна звездочка — это подстановочный знак, который может соответствовать как нескольким символам, так и ни одному.
*.log !important.log	debug.log trace.log но не important.log logs/important.log	Добавление восклицательного знака в начало шаблона отменяет действие шаблона. Если файл соответствует некоему шаблону, но при этом также соответствует отменяющему шаблону, указанному после, такой файл не будет игнорироваться.
.log !important/.log trace.*	debug.log important/trace.log но не important/debug.log	Шаблоны, указанные после отменяющего шаблона, снова будут помечать файлы как игнорируемые, даже если ранее игнорирование этих файлов было отменено.
/debug.log	debug.log но не logs/debug.log	Косая черта перед именем файла соответствует файлу в корневом каталоге репозитория.
debug.log	debug.log logs/debug.log	По умолчанию шаблоны соответствуют файлам, находящимся в любом каталоге
debug?.log	debug0.log debugg.log но не debug10.log	Знак вопроса соответствует строго одному символу.
debug5.log	debug0.log debug1.log но не debug10.log	Квадратные скобки можно также использовать для указания соответствия одному символу из заданного диапазона.
debug[01].log	debug0.log debug1.log но не debug2.log debug01.log	Квадратные скобки соответствуют одному символу из указанного набора.
debug[!01].log	debug2.log но не debug0.log debug1.log debug01.log	Восклицательный знак можно использовать для указания соответствия любому символу, кроме символов из указанного набора.
debug[a-z].log	debuga.log debugb.log но не debug1.log	Диапазоны могут быть цифровыми или буквенными.
logs	logs logs/debug.log logs/latest/foo.bar build/logs build/logs/debug.log	Без косой черты в конце этот шаблон будет соответствовать и файлам, и содержимому каталогов с таким именем. В примере соответствия слева игнорируются и каталоги, и файлы с именем logs
logs/	logs/debug.log logs/latest/foo.bar build/logs/foo.bar build/logs/latest/debug.log	Косая черта в конце шаблона означает каталог. Все содержимое любого каталога репозитория, соответствующего этому имени (включая все его файлы и подкаталоги), будет игнорироваться
logs/ !logs/important.log	logs/debug.log logs/important.log	Минуточку! Разве файл logs/important.log из примера слева не должен быть исключен нз списка игнорируемых? Нет! Из-за странностей Git, связанных с производительностью, вы не можете отменить игнорирование файла, которое задано шаблоном соответствия каталогу
logs/**/debug.log	logs/debug.log logs/monday/debug.log logs/monday/pm/debug.log	Две звездочки соответствуют множеству каталогов или ни одному.
logs/*day/debug.log	logs/monday/debug.log logs/tuesday/debug.log but not logs/latest/debug.log	Подстановочные символы можно использовать и в именах каталогов.
logs/debug.log	logs/debug.log но не debug.log build/logs/debug.log	Шаблоны, указывающие на файл в определенном каталоге, задаются относительно корневого каталога репозитория. (При желании можно добавить в начало косую черту, но она ни на что особо не повлияет.)

Что если файлы из gitignore уже добавлены в репозиторий

Обратите внимание, что если файлы уже добавлены в git репозиторий, то добавление их в .gitignore не удалит эти файлы. Изменения в них будут продолжать отслеживаться и входить в коммиты, несмотря на то, что они есть в .gitignore .

Нам придется вручную их удалить из репозитория.

Очень удобная команда bash, которая удалит из git репозитория те файлы, которые содержатся в файлах .gitignore :

То же самое для Powershell

При выполнении этой команды, файлы останутся у вас на диске, однако из репозитория они будут удалены.

Либо можно удалять файлы вручную, таким образом:

Либо если нам нужно удалить целую директорию из git, то воспользуемся следующей командой:

Либо так мы могли бы удалить все файлы с расширением .log в папке log:

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

Как понять, почему игнорируется конкретный файл

Запустите команду вместо path/to/file следует указать путь к файлу.

В итоге мы получим ответ, в котором содержится конкретная строка .gitignore, благодаря которой данный файл игнорируется.

Ранее мы уже говорили об одной ситуации, когда .gitignore "не работает", в этой же заметке рассмотрим ситуацию связанную уже непосредственно с правилами написанными в этом файле.

Сразу скажем, что проверять работу правил можно такой командой.

Главная мысль

Если родительская папка (а не её содержимое) данного элемента была проигнорирована ранее в каком-то правиле, то уже не получается отменить данном правило для её потомка.

It is not possible to re-include a file if a parent directory of that file is excluded.

-- это было актуально до версии 2.8 в будущем, может быть исправят.

Пример

Пусть у нас есть директория, в которой мы хотим всё игнорировать, кроме самой этой директории -- в этом случае нам достаточно закинуть в неё такой .гитигнор:

Но предположим, что нам захотелось не игнорировать ещё одну подпапку (в этой) скажем её название images -- то есть нам тоже хочется сделать, чтобы она сохранилась по контролем, а содержимое не нужно. Тогда если мы напишем так:

(используем .gitkeep) -- то исключение
!images/.gitkeep уже не сработает так как предыдущее правило звездочки * уже отправила родительскую для гиткипа папку в игнор (см. "Главную мысль" выше).

Как правильно сохранить поддиректорию без содержимого в .gitignore если нужно игнорировать родителя

А потому правильно сохранить подпапку можно так (содержимое игнора родительской папки):

Я не знаю ни одного проекта, в рабочей директории которого не появлялось бы таких файлов, которые не нужно игнорировать. Зачастую, у вас имеется группа файлов, которые вы не только не хотите автоматически добавлять в репозиторий, но и видеть в списках неотслеживаемых (а чем взрослее проект, тем больше таких файлов может быть). К таким файлам обычно относятся автоматически генерируемые файлы (различные логи, результаты сборки программ и т.п.).

Как я говорил в вводной лекции, в таком случае, вы можете создать файл .gitignore с перечислением шаблонов соответствующих таким файлам. Хорошая практика заключается в настройке файла .gitignore до того, как начать серьёзно работать, это защитит вас от случайного добавления в репозиторий файлов, которых вы там видеть не хотите.

Вот пример файла .gitignore для типового Rails приложения (пример взят с github и является стандартом де-факто для большинства репозиториев с проектами на Ruby on Rails):

Давайте повнимательнее рассмотрим этот файл: В первой строке написано, что необходимо игнорировать все файлы, которые заканчиваются на .rbc, в четвертой, что необходимо игнорировать директорию log, в шестой - все файлы конфигураций баз данных sqlite3. Сразу видно, что для большинства правил используются некоторые шаблоны. Но можно указывать и полный путь до конкретного файла, как сделано в 15 и 16 строках. Git всегда мягко применяет эти правила. Если вы указали, что необходимо игнорировать просто строку test - то он будет игнорировать и директории (вместе со вложенными файлами) и файлы, которые называются test, вне зависимости, где они располагаются. Если вы хотите ограничиться только корневым уровнем в репозитории - необходимо явно это указать поставив “/” перед шаблоном.

К шаблонам в файле .gitignore применяются следующие правила:

Шаблон **/ доступен в Git, начиная с версии 1.8.2.

Временно игнорировать изменения в файле можно командой:

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

Однако, стоит быть осторожнее с командой git rm.

Однако, стоит обратить внимание на то, что файл .gitignore не решение от всех проблем. То есть он проблему то решает, но не стоит его всегда использовать. Иногда встречаю в файле .gitignore то, чего там быть никак не должно. Давайте представим такую ситуацию: Я и вы работаем в одной команде над одним проектом. Я в своей работе использую vim, а вы, например, IDE от JetBrains. У меня временные файлы создаются в специальном каталоге в профиле пользователя, тем самым в директории проекта я никак не создаю временных файлов при редактировании проекта. У вас же в проекте создается директория .idea, в которой лежат конфиги вашей IDE для этого проекта. Это часть вашего рабочего окружения и она никаким боком не относится к проекту и репозиторию. По идее, вы можете добавить строчку /.idea в файл .gitignore в проекте, однако, если над проектом работает несколько человек и каждый из них добавит конфиги своего окружения в .gitignore, то он превратится в нечитаемую помойку.

Что делать и как быть? Есть несколько разных способов игнорирования файлов в git.

Этот как раз тот самый .gitignore, в корне репозитория. В него стоит помещать в основном только то, что имеет непосредсвенное оношение к проекту и его архитектуре. Например, у всех участников проекта есть директория с локами, или у всех в одном и том же месте создаются временные файлы. Если эти правила имеют отношение ко всем участникам проекта - то стоит правила игнорирования разместить в .gitignore, который будет распространяться вместе с репозиторием.

Когда у вас несколько проектов и везде создается что-либо, что вы не хотите коммитить(например, *.swp файлы Vim) используйте ~/.gitconfig. Вышеприведённый пример папки .idea, которая создается для каждого проекта как раз подходит сюда. Создайте файл .gitexcludes и выполните:

или вручную добавьте в ~/.gitconfig:

Иногда возможны случаи, когда у вас есть файлы, которые специфичны для данного проекта и для вашего рабочего окружения (например, логи third-party утилиты, которую вы любите использовать и используете только в этом проекте). К проекту отнести шаблон игнорирования - не верно. Вы не используете ее во всех проектах и значит игнорировать глобально на всем компьютере - тоже не стоит. В данном случае используйте .git/info/exclude. Этот файл не коммитится и остается только в локальном репозитории.

Сразу после сохранения ~/.gitconfig вы не должны видеть указанные файлы/папки в списке Untracked files.

Я люблю Git, но и он порой непоследователен в мелочах. Обращаю ваше внимание на то, что в первом случае мы редактируем файл.git/info/exclude (без s на конце), а во втором используем опцию excludeSfile (c s в середине). Не потеряйте время из-за возможной опечатки.

Работа с Git в большинстве случаев означает работу в команде, поэтому не усложняйте жизнь тем, кто будет работать с вами деталями вашего рабочего окружения. Хороших коммитов! :)

Не все файлы, созданные или обновленные в коде, следует фиксировать в Git. Временные файлы из среды разработки, тестовые выходные данные и журналы — все это примеры файлов, которые создаются, но не являются частью базы кода. Настройка файлов, отслеживаемых Git с помощью функции gitignore .

Из этого руководства вы узнаете, как выполнить следующие задачи:

Использование gitignore для предотвращения отслеживания файлов
Пропускать файлы только в вашей системе
Пропускать файлы во всех репозиториев в системе
Игнорировать изменения в зафиксированных файлах

Использование gitignore для предотвращения отслеживания файлов

Создайте gitignore -файл в репозитории Git, чтобы не допустить размещения в Git нежелательных файлов. Share . gitignore в ветви по умолчанию в репозитории. Вы и ваша команда можете обновить файл, чтобы изменить типы файлов, которые следует игнорировать.

Создание. gitignore

Visual Studio 2019 версии 16,8 и более поздних версий предоставляют новое меню Git для управления рабочим процессом git с меньшим переключением контекста, чем Team Explorer. процедуры, описанные в этой статье на вкладке Visual Studio 2019, содержат сведения о работе с Git и Team Explorer. Дополнительные сведения см. в разделе параллельное сравнение Git и Team Explorer.

Visual Studio автоматически создает файл . gitignore в репозитории при создании нового репозитория для проекта.

Скачайте файл template. gitignore для типа проекта и настройте его в соответствии с вашими потребностями. Если проект не соответствует шаблону, можно создать пустой . gitignore из командной строки. Перейдите в репозиторий Git и выполните одну из следующих команд, используя сведения о репозитории:

Windows

Linux и macOS

Git применяет . gitignore к папке и вложенным папкам, где она находится. Мы рекомендуем разместить . gitignore в корневой папке репозитория, чтобы избежать путаницы.

Настройка. gitignore

Измените gitignore , чтобы включить в репозиторий типы файлов, пути и шаблоны файлов. Git начинает пропускать эти файлы сразу после обновления . gitignore. Если другим пользователям вашей команды требуется один и тот же набор игнорируемых файлов, обязательно зафиксируйте изменения.

чтобы изменить файл gitignore для репозитория, перейдите в представление Параметры в Team Explorer, а затем выберите репозиторий Параметры. Выберите изменить для gitignore.

Используйте текстовый редактор, например следующий пример, в котором используется vim:

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

Windows users: все пути к файлам в gitignore -файле используют разделитель косой черты, а не обратную косую черту.

Пропускать файлы только в вашей системе

Ваш gitignore является общим для участников команды, так как файл зафиксирован и отправлен в репозиторий Git. Чтобы исключить файлы только в системе, измените файл . git/info/Exclude в локальном репозитории. Изменения в этом файле не являются общими для других пользователей. Они применяются только к файлам в этом репозитории. Для этого файла используется тот же синтаксис , что и в файле. gitignore.

Пропускать файлы во всех репозиториев в системе

Настройте Global . gitignore для использования во всех репозиториев в системе с помощью программы командной строки , как показано в следующем примере:

Этот подход удобен для игнорирования целых типов файлов, которые вы не хотите зафиксировать, например скомпилированных двоичных файлов.

Игнорировать изменения в зафиксированных файлах

Временно игнорировать изменения

Во время разработки удобно отключить отслеживание изменений файлов в файле, зафиксированном в репозитории Git. Этот подход удобен при настройке параметров или файлов конфигурации, которые являются частью источника проекта, для собственной рабочей среды.

Возобновление отслеживания файлов с помощью следующей команды:

Вместо этого можно использовать следующие параметры. Эти параметры предназначены главным образом для отметки файлов, которые не должны изменяться разработчиками.

Чтобы отключить отслеживание изменений, выполните следующие действия.

Чтобы возобновить отслеживание изменений, выполните следующие действия.

Безвозвратная отмена отслеживания файла

Если файл уже записан в Git, он .gitignore не применяется. Git продолжит отслеживание изменений в этом файле.

Если вы хотите отключить отслеживание файла, необходимо явно указать git, который он должен удалить из отслеживания. Следуя этим указаниям, файл останется в локальном рабочем каталоге, но не будет относиться к записи в Git.

Добавьте файл в .gitignore .

Выполните следующую команду:

Зафиксируйте удаление файла и обновленный файл . gitignore в репозитории.

GitHub зарекомендовал себя как один из пионеров в области совместной работы над кодом и совместного использования репозитория. GitHub - это в основном программное обеспечение для контроля версий, которое позволяет пользователям контролировать распределенный контроль версий и управление исходным кодом (SCM). Эта платформа используется крупными компаниями и компаниями по всему миру.

Что делает .gitignore не работает?

Функция .gitignore может работать правильно, но вы, возможно, настроили ее неправильно. Во всех наших исследованиях мы пришли к выводу, что модуль действительно работает. Основная причина, по которой программисты не могут использовать эту функцию, заключается в том, что они неправильно сконфигурировали файл или потому, что существуют определенные условия, которые не выполняются в базовом коде.

Игнорируемые файлы - это, как правило, артефакты компиляции и файлы, сгенерированные машиной, которые могут быть получены из источников вашего хранилища или которые не должны передаваться иным образом

Вот некоторые решения, которые могут быть правильными для вас. Любое решение может быть неприменимо в вашем случае, поэтому обязательно переходите к следующему решению, если начальные условия не выполнены.

Очень быстрое решение этой проблемы - избавиться от любых пробелов в файле .gitignore, если вы их найдете. Кроме того, вы не должны размещать комментарии рядом с файлом, указанным в файле .gitignore.

Если кажется, что Git не замечает изменений, которые вы внесли в ваш файл.gitignore, вам следует проверить следующие моменты:

Это может быть файл global.gitignore, который может помешать вашему локальному файлу.

Если вы добавляете что-то в файл a.gitignore, попробуйте это:

Удалить отслеживаемые файлы из хранилища

Обновление за январь 2022 года:

Теперь вы можете предотвратить проблемы с ПК с помощью этого инструмента, например, защитить вас от потери файлов и вредоносных программ. Кроме того, это отличный способ оптимизировать ваш компьютер для достижения максимальной производительности. Программа с легкостью исправляет типичные ошибки, которые могут возникнуть в системах Windows - нет необходимости часами искать и устранять неполадки, если у вас под рукой есть идеальное решение:

Будьте последовательны с мастером

Прежде чем пытаться выполнить команду с этой станции, убедитесь, что вы подтвердили все изменения, которые вы сделали локально, а также что вы получили основной код из вашего локального репо, который сделали другие.

Переустановка файлов в хранилище

Если вы уже добавили правила в .gitignore, но файлы, которые вы хотите игнорировать, уже добавлены, мы можем добавить их снова. Добавление означает, что мы удаляем все из индекса git и затем добавляем его в ваш репозиторий. Когда мы снова добавляем файлы с нуля, правила, добавленные вами в .gitignore, учитываются и добавляются только нужные файлы.

Заключение

Это должно быть так. Git - один из самых мощных инструментов, которые мы когда-либо видели в нашей жизни. Это делает нашу жизнь проще. Чем сложнее ваша конфигурация, тем проще управлять этими инструментами управления версиями кода.

CCNA, веб-разработчик, ПК для устранения неполадок

Я компьютерный энтузиаст и практикующий ИТ-специалист. У меня за плечами многолетний опыт работы в области компьютерного программирования, устранения неисправностей и ремонта оборудования. Я специализируюсь на веб-разработке и дизайне баз данных. У меня также есть сертификат CCNA для проектирования сетей и устранения неполадок.

Читайте также: