Webdevkin
Онлайн-курсы, статьи по веб-разработке и интернет-магазинам, уроки vue.js

Изучаем Git. Урок 11.
.gitignore и git exclude

Урок, в котором мы узнаем, что такое gitignore и exclude, как с ними работать и чем они отличаются

Видеоурок

Конспект урока

Краткое содержание урока, основные инструкции для командной строки, полезные ссылки и советы.

Зачем нужен .gitignore

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

Такие файлы объединяют 2 вещи:
1. нам не нужно отслеживать в них изменения
2. нам не нужно делиться ими с коллегами

Для решения этой задачи у гита есть специальный файл .gitignore, в котором построчно записываются игнорируемые файлы или папки. Мы создадим его в корне проекта и рассмотрим примеры таких исключаемыйх файлов и папок

Пример 1. Служебные файлы IDE

PhpStorm создает служебную папку .idea, а корне проекта. В нее входят файлы, нужные для работы IDE, но не нашего приложения. Поэтому ее можно исключить из отслеживаемых гитом такой строкой

При этом все файлы из папки .idea попадут в неотслеживаемые и мы не сможем их случайно закоммитить.

Пример 2. Библиотеки, скачанные через пакетные менеджеры

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

Типичный пример - npm и папка node_modules во фронтенд-разработке. Конфигурационные файлы package.json и package-lock.json нужно отслеживать гитом, потому что там содержится информация о библиотеках. А папку node_modules нет, потому что там лежат файлы самих библиотек, которые легко устанавливаются запуском команды npm i из папки с файлом package.json

Поэтому node_modules добавляется в .gitignore как и папка с конфигами IDE

Пример 3. Логи

Допустим, мы разрабатываем веб-приложение и хотим, чтобы логи nginx находились в папке проекта. Пусть это будет папка logs в корне проекта с двумя файлами error.log и access.log.

Плюс рядом с package.json появляется файл npm-debug.log, который нам тоже не нужен

Исключить эти файлы можно по отдельности

А можно универсально

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

Пример 4. Файлы сборки фронта

Часто фронтенд-приложение содержит в себе 2 папки: src и dist. В src лежат исходники кода, которые мы редактируем. Содержимое папки dist формируется при сборке проекта инструментом вроде webpack-a. Файлы из папки dist не редактируются и также добавляются в .gitignore

Как понять, добавлять ли файл или папку в .gitignore или нет?

Задайте себе вопрос: нужен ли этот файл или папка другому разработчику?

Если не нужен, то добавляйте его в .gitignore

Тонкая настройка .gitignore

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

Например, можно исключать вложенные папки, можно исключить всю папку кроме некоторых файлов. Ознакомиться с полным списком примеров можно в неплохом туториале от bitbucket

Несколько файлов .gitignore

Мы рассмотрели случай с одним .gitignore в корне проекта, но их можно создавать множество, хоть в каждой папке проекта. В таком подходе есть и плюсы, и минусы

Плюсы:
1. не нужно прописывать длинные пути к вложенным папкам
2. не разрастается корневой .gitignore

Минус. Один, но очень большой

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

Поэтому лучше придерживаться правила - один .gitignore в корне проекта. Тогда он будет единой точкой входа и вся информация окажется в одном месте

Когда есть смысл использовать несколько .gitignore

В случае, когда в одном репозитории четко разделены несколько направлений. Например, у проекта такая структура папок:

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

P.S. Конечно, в таком случае лучше разнести все эти папки в отдельные репозитории, но это совсем другая история

git exclude

exclude - это тоже самое, что и .gitignore, но с одним важным отличием

.gitignore отслеживается гитом. То есть изменения в нем комитятся и отправляются на сервер

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

Пример работы с git exclude

Есть мнение, что служебные файлы IDE не стоит добавлять в .gitignore, а нужно исключать их локально. Вопрос спорный, но для примера сделаем так - уберем папку .idea/ из .gitignore и добавим ее в файл .git/info/exclude

Так как папка .git/ это служебная папка гита, то она скрытая, и скорее всего в IDE вы ее не увидите. Но можно отредактировать этот файл в терминале

После этого папка .idea перестанет отслеживаться у вас в гите, точно так же, как бы она была указана в gitignore. Но так как этот .git/info/exclude находится только на локальной машине, то это правило работает только для вас, а вашим коллегам придется прописывать исключения вручную, если они тоже работают в IDE от jetbrains.

Какие файлы добавлять в git exclude, то есть исключать их локально

На мой взгляд, нет причин исключать какие-то файлы локально. Сторонники exclude говорят, что как минимум файлы IDE нужно исключать локально, но даже если люди на проекте используют самые разные IDE, нет ничего плохого в том, чтобы прописать отдельные правила для каждой IDE - по 2-3 строчки на каждую

Единственный вариант, который приходит мне в голову - если вы держите в папке с проектом файлы cat.jpg и secret-email-from-boss.txt. Но это маловероятно

Поэтому знать о возможности git exclude не помешает, но используйте осторожно - когда вы точно знаете, что исключаемые файлы 100% находятся только у вас

Ресурсы в помощь

Есть специальные сервисы, помогающие генерировать .gitignore под ваш проект. Например, gitignore.io

Вам нужно только накидать ключевых слов, которые относятся к вашему проекту, например, phpstorm, vuejs и modx - а сервис выдаст готовый .gitignore

Штука удобная, но рекомендую использовать ее скорее как шаблон для собственного .gitignore, похоже, что сервис генерит много лишних правил по принципу "много не мало"

Через некоторое время работы с гитом у вас сформируется свой .gitignore, который вы будете просто переносить из проекта в проект с небольшими изменениями

На этом все. И мемасик напоследок

.gitignore

Спасибо за внимание и до встречи!

Следующий урок ⇨
Урок 12. Работа с git stash

⇦ Предыдущий урок
Урок 10. Конфликты и их разрешение

Все уроки курса

* платные уроки

список обновляется...