Для чего нужен gitignore
.gitignore
Git рассматривает каждый файл в вашей рабочей копии как файл одного из трех нижеуказанных типов.
Игнорируемые файлы — это, как правило, артефакты сборки и файлы, генерируемые машиной из исходных файлов в вашем репозитории, либо файлы, которые по какой-либо иной причине не должны попадать в коммиты. Вот некоторые распространенные примеры таких файлов:
Шаблоны игнорирования в Git
| Шаблон | Примеры соответствия | Пояснение* |
|---|---|---|
| **/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 | Знак вопроса соответствует строго одному символу. |
| debug4.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 | Шаблоны, указывающие на файл в определенном каталоге, задаются относительно корневого каталога репозитория. (При желании можно добавить в начало косую черту, но она ни на что особо не повлияет.) |
Персональные правила игнорирования в Git
Глобальные правила игнорирования в Git
Игнорирование ранее закоммиченного файла
Коммит игнорируемого файла
Этот способ хорош, если у вас задан общий шаблон (например, *.log ), но вы хотите сделать коммит определенного файла. Однако еще лучше в этом случае задать исключение из общего правила:
Этот подход более прозрачен и понятен, если вы работаете в команде.
Скрытие изменений в игнорируем файле
При желании команде git check-ignore можно передать несколько имен файлов, причем сами имена могут даже не соответствовать файлам, существующим в вашем репозитории.
Готовы изучить Git?
Ознакомьтесь с этим интерактивным обучающим руководством.
В большинстве проектов есть разница между кодом / конфигурацией и сгенерированные файлы из этого кода или конфигурации. Последнее обычно бесполезно, и его можно игнорировать.
Обычно вы хотите, чтобы код и конфигурация отслеживались только через git. Это связано с тем, что сгенерированные файлы эфемерны, и если вы удалите их, вы можете просто восстановить их снова. Часто нет смысла загружать их, поскольку они просто усложнят ситуацию и вызовут ненужные конфликты слияния.
Это широкое определение, поэтому давайте рассмотрим пример. В проектах Node JS есть папка с именем node_modules, которая содержит все внешние пакеты, которые необходимо запустить вашему коду. Вы можете удалить этот каталог и полностью перестроить его, запустив команду npm install, которая использует конфигурацию package.json для поиска пакетов.
Так какой смысл иметь папку node_modules в Git? На самом деле его нет, так как он более сложный, может вызвать проблемы и даже во многих случаях может значительно увеличить размер репозитория Git.
Вы можете настроить это разными способами, но основные инструменты, которые у вас есть:
Например, Node JS gitignore может выглядеть следующим образом:
Добавление файлов в белый список с помощью! может быть очень полезным для многих конфигураций. Например, в одном из моих проектов у меня был инструмент steamcmd, который загружает зависимости для игровых серверов из Steam. Этот инструмент упакован в один переносимый исполняемый файл, но он производит огромное количество мусора, который я не хочу отслеживать в Git.
Решением было игнорировать все в папке, но занести исполняемый файл в белый список. Это будет работать для любого переносимого исполняемого файла, который расширяется таким образом или создает в каталоге ненужный мусор.
Проект / steamcmd / **! Project / steamcmd / steamcmd.exe
gitignore также использует некоторые другие Unix шарик шаблоны для сопоставления строк, например вопросительный знак для сопоставления одного символа или [a-z] который будет соответствовать наборам символов.
# Результаты сборки
[Dd]ebug /
[Dd]ebugPublic /
[Rr]elease /
[Rr]eleases /
Если вы все равно хотите установить его, вы можете сделать это с помощью следующей команды:
git config —global core.excludesfile
Принудительная фиксация или сохранение игнорируемых файлов
Принудительная фиксация, как правило, плохая идея — вам, вероятно, следует добавить белый список для этого конкретного файла, потому что после фиксации обновления этого файла не будут отслеживаться. Но если вы хотите что-то зафиксировать вручную, вы можете запустить git add с параметром —force:
Точно так же git stash также может хранить локальные изменения в игнорируемых файлах, что на самом деле может быть полезно, поскольку не повлияет на удаленное репо:
Содержание
.gitignore служит для указания в нём файлов и папок, которые необходимо скрыть от системы контроля версий git.
Как правило, скрывают файлы или папки, которые автоматически генерируют своё содержимое, либо имеют конфигурационные параметры, которые могут различаться у тех, кто совместно работает над проектом.
Приведу простой пример: у вас имеется файл «/config/db.php«, в нём прописаны параметры подключения к БД, причём на вашей локальной машине и на сервере эти параметры будут разниться. А если эти файлы различны, то git будет при каждом pull/push ругаться на то, что имеется конфликт.
Другой пример: если вы используете NetBeans и настройки своего проекта храните непосредственно в папке с проектом, то вам необходимо закрыть от git`а директорию «nbproject«, чтобы другие участники вашего проекта не страдали от того, что вы случайно закомитили эту директорию.
Данная ситуация легко разрешатся использованием файла .gitignore, который можно разместить в папке «/config/.gitignore» со следующим содержимым:
Одна эта строчка укажет git, что необходимо игнорировать файл » db.php«, который лежит в этой директории.
Вот некоторые правила синтаксиса этого файла:
У некоторых может возникнуть вопрос:
Ответ таков: Нужно удалить из репозитория игнорируемые файлы/директории, делается это командой. После этого файл окончательно пропадёт из отслеживаемых git`ом.
Игнорирование файлов и каталогов в Git (.gitignore)
Какие файлы следует игнорировать?
Игнорируемые файлы обычно представляют собой файлы для конкретной платформы или автоматически созданные файлы из систем сборки. Вот некоторые общие примеры:
.gitignore Шаблоны
.gitignore — это простой текстовый файл, в каждой строке которого содержится шаблон, который файлы или каталоги следует игнорировать.
Он использует шаблоны подстановки для сопоставления имен файлов с подстановочными знаками. Если у вас есть файлы или каталоги, содержащие шаблон подстановки, вы можете использовать одиночную обратную косую черту ( ) для экранирования символа.
Комментарии
Строки, начинающиеся с решетки ( # ), являются комментариями и игнорируются. Пустые строки можно использовать для улучшения читаемости файла и для группировки связанных строк шаблонов.
Если шаблон начинается с косой черты, он соответствует файлам и каталогам только в корне репозитория.
Если шаблон не начинается с косой черты, он соответствует файлам и каталогам в любом каталоге или подкаталоге.
Если шаблон заканчивается косой чертой, он соответствует только каталогам. Когда каталог игнорируется, все его файлы и подкаталоги также игнорируются.
Буквальные имена файлов
Самый простой шаблон — это буквальное имя файла без каких-либо специальных символов.
| Шаблон | Примеры совпадений |
|---|---|
| /access.log | access.log |
| access.log | access.log logs/access.log var/logs/access.log |
| build/ | build |
Подстановочные символы
* — символ звездочки соответствует нулю или более символам.
| Шаблон | Примеры совпадений |
|---|---|
| *.log | error.log logs/debug.log build/logs/error.log |
** — Два соседних символа звездочки соответствуют любому файлу или нулю или более каталогам. Если за ним следует косая черта ( / ), он соответствует только каталогам.
? — Знак вопроса соответствует любому одиночному символу.
| Шаблон | Примеры совпадений |
|---|---|
| access?.log | access0.log access1.log accessA.log |
| foo?? | fooab foo23 foo0s |
Квадратных скобок
| Шаблон | Примеры совпадений |
|---|---|
| *.[oa] | file.o file.a |
| *.[!oa] | file.s file.1 file.0 |
| access.2.log | access.0.log access.1.log access.2.log |
| file.[ac].out | file.a.out file.b.out file.c.out |
| file.[a-cx-z].out | file.a.out file.b.out file.c.out file.x.out file.y.out file.z.out |
| access.[!0-2].log | access.3.log access.4.log access.Q.log |
Отрицательные паттерны
| Шаблон | Примеры совпадений |
|---|---|
| *.log !error.log | error.log или logs/error.log не будут проигнорированы |
.gitignore Пример
Шаблоны, определенные в файлах, которые находятся в каталогах (подкаталогах) более низкого уровня, имеют приоритет над шаблонами в каталогах более высокого уровня.
Личные правила игнорирования
Например, вы можете использовать этот файл, чтобы игнорировать файлы, сгенерированные из ваших личных инструментов проекта.
Файл можно назвать как угодно и хранить в любом месте. Чаще всего этот файл хранится в домашнем каталоге. Вам придется вручную создать файл и настроить Git для его использования.
Например, чтобы установить
/.gitignore_global в качестве глобального файла игнорирования Git, вы должны сделать следующее:
Добавьте файл в конфигурацию Git:
Откройте файл в текстовом редакторе и добавьте в него свои правила.
Глобальные правила особенно полезны для игнорирования определенных файлов, которые вы никогда не хотите фиксировать, например файлов с конфиденциальной информацией или скомпилированных исполняемых файлов.
Игнорирование ранее зафиксированных файлов
Файлы в вашей рабочей копии можно отслеживать или нет.
Например, чтобы проверить, почему файл www/yarn.lock игнорируется, вы должны запустить:
Команда также принимает в качестве аргументов более одного имени файла, и файл не обязательно должен существовать в вашем рабочем дереве.
Отображение всех игнорируемых файлов
Выводы
Если у вас есть какие-либо вопросы или отзывы, не стесняйтесь оставлять комментарии.
3 ответа 3
Стоит подумать
Как правило, нельзя игнорировать, нужно сохранять
В дополнение к ответу @Nick Volynkin
Обязательно системные файлы ОС и бекапы
Файлы самих IDE (если вы работаете на локалке)
Разные плагины
Файловая система
Дополнение
Из комментария @Timofey Bondarev
А я вот сейчас влезу и выскажу непопулярное мнение.
Файлы, о которых надо ТРИЖДЫ подумать
Файлы IDE и всего к нему подключаемого. Вам нужно понимать, какие файлы и для чего нужны. Ради примера:
R# + C#: MySolution.sln.DotSettings — «командные» настройки для проекта, MySolution.sln.DotSettings.user — «личные» настройки для проекта (есть ещё «системные», они в другом месте лежат). Нужно не только следить, чтобы заигнорен был правильный файл, но и чтобы изменённые настройки попадали в нужный файл, иначе с командой будут разногласия.
Генерируемые при сборке файлы. В разных языках и средах разные традиции, а вокруг отдельных файлов разгораются нешуточные споры. Ради примера:
Composer + PHP: Хранить или не хранить composer.lock — зависит от приоритетов команды, библиотеку или приложение вы разрабатываете, и от личных вкусов. Вам нужно хорошо понимать, какие плюсы и минусы у нахождения файла в репозитории.
T4 + C#: В C# принято хранить вывод кодогенерации, чтобы можно было легко собрать проект. При этом можно настроить сборку, чтобы кодогенерация запускалась при сборке, однако это возможно не для всех скриптов. Надо отметить, что кодогенерация не из T4 обычно попадает в Output, поэтому игнорируется. В других языках и средах чаще исповедуют идеологию, что вывод кодогенерации никогда не коммитится.
Бинарники. Git отвратительно работает с бинарниками, в отличие от «отсталых» VCS типа SVN. Репозиторий непомерно разрастается, если файлы часто обновлять.
Если вы обновляете файлы редко, и они мелкие, то можно положить файлы на место.
В противном случае лучше спрятать файлы в какое-нибудь другое место. Есть как универсальные костыли для Git (Git LFS), так и специфические для языка и среды инструменты (личный сервер NuGet).
Если вы можете использовать NuGet, Composer, CPAN, Lein, Maven, то используйте. Бинарные зависимости должны быть там.
Идеал
Вы должны стремиться к тому, чтобы в репозитории было минимальное возможное количество файлов, которых достаточно для сборки всего проекта абсолютно без вмешательства и настройки чего бы то ни было.
Часто идеал недостижим. Так что ищите компромисс.