5 файлов Git Dotfiles, которые должен знать каждый разработчик
Большинство разработчиков знакомы с .gitignore, но экосистема конфигурации Git гораздо глубже. Разбросанные по вашему домашнему каталогу и корневым директориям проектов, несколько важных файлов Git dotfiles незаметно определяют поведение вашего репозитория, то, как коллеги воспринимают вашу кодовую базу, и насколько последовательно Git работает на разных машинах. Понимание этих файлов избавит вас от незаметных багов, запутанной истории и трений при совместной работе.
Вот пять конфигурационных файлов Git, которые стоит хорошо знать.
Ключевые выводы
- Конфигурация Git работает на четырёх уровнях (system, global, repository, worktree), и
.gitconfigподдерживает директивыincludeIfдля портативных, контекстно-зависимых настроек. .gitignoreвлияет только на неотслеживаемые файлы. Используйте глобальный файл игнорирования для артефактов редактора и ОС, чтобы игнорирование на уровне проекта оставалось сфокусированным..gitattributesконтролирует гораздо больше, чем окончания строк — он управляет поведением слияния, обработкой бинарных файлов, драйверами diff и поведением экспорта..git-blame-ignore-revsспасаетgit blameот массовых коммитов форматирования, и GitHub распознаёт его автоматически..mailmapнормализует идентичности участников в истории вашего проекта, обеспечивая точную атрибуцию в логах и статистике.
1. .gitconfig — Ваша личная идентичность и поведение Git
Расположение: ~/.gitconfig (глобальный) или .git/config (на уровне репозитория)
.gitconfig — это основной конфигурационный файл Git для вашей учётной записи пользователя. Он хранит ваше имя, email, редактор по умолчанию, алиасы и поведенческие предпочтения. Конфигурация Git может существовать на нескольких уровнях: system (системный), global (глобальный), local (repository) (локальный/репозиторий) и опционально worktree (рабочее дерево), при этом более специфичные конфигурации переопределяют более широкие.
Практический паттерн, заимствованный из реальных настроек dotfile: храните ~/.gitconfig для общих настроек и используйте директивы includeIf для загрузки переопределений, специфичных для машины или работы, не засоряя основную конфигурацию.
[includeIf "gitdir:~/work/"]
path = ~/.gitconfig_work
Это сохраняет ваши dotfiles портативными, одновременно учитывая различия между машинами — то, что простой подход с символическими ссылками не может обеспечить чисто. Вы можете узнать больше об условной конфигурации в официальной документации по конфигурации Git.
2. .gitignore — Держим неотслеживаемые файлы вне индекса
Расположение: корень проекта, подкаталоги или ~/.config/git/ignore (глобальный)
.gitignore влияет только на неотслеживаемые файлы. Он не удалит файлы, уже закоммиченные в репозиторий. Это распространённый источник путаницы — если вам нужно прекратить отслеживание закоммиченного файла, сначала необходимо выполнить git rm --cached <file>, прежде чем правило игнорирования вступит в силу.
Для файлов, которые вы хотите игнорировать глобально — swap-файлы редактора, .DS_Store, миниатюры ОС — настройте глобальный файл игнорирования через core.excludesFile в вашем .gitconfig:
[core]
excludesFile = ~/.config/git/ignore
Это сохраняет файлы .gitignore проекта чистыми и сфокусированными на исключениях, специфичных для проекта, вместо того чтобы быть захламлёнными личными предпочтениями редактора каждого разработчика. Официальная документация gitignore подробно объясняет правила сопоставления и приоритет.
3. .gitattributes — Больше, чем просто окончания строк
Расположение: корень проекта (коммитится в репозиторий)
.gitattributes — один из самых недоиспользуемых файлов Git dotfiles. Да, он обрабатывает нормализацию окончаний строк (text=auto), но он также контролирует:
- Поведение слияния — настраивает, как сливаются определённые типы файлов
- Обработку бинарных файлов — указывает Git не делать diff или слияние определённых типов файлов
- Поведение экспорта — используйте
export-ignore, чтобы исключить файлы из выводовgit archive(полезно для артефактов CI) - Драйверы diff — назначает человекочитаемый вывод diff для форматов вроде
.docxили минифицированного JS
Для фронтенд-проектов маркировка lockfile-ов или собранных ресурсов соответствующими атрибутами предотвращает ненужные конфликты слияния и шум в diff. Полный диапазон атрибутов и поведений описан в официальной документации gitattributes.
Discover how at OpenReplay.com.
4. .git-blame-ignore-revs — Очистка blame после коммитов форматирования
Расположение: корень проекта (коммитится в репозиторий)
Когда вы запускаете форматтер вроде Prettier или ESLint на всей кодовой базе, git blame становится практически бесполезным — каждая строка указывает на коммит форматирования, а не на оригинального автора.
.git-blame-ignore-revs решает эту проблему. Перечислите полные SHA коммитов, которые blame должен пропустить:
# Prettier formatting pass
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
Затем настройте Git на его использование:
git config blame.ignoreRevsFile .git-blame-ignore-revs
GitHub распознаёт этот файл автоматически. Это небольшое дополнение со значительным влиянием на code review и читаемость истории. Поведение документировано в официальной документации git blame.
5. .mailmap — Нормализация идентичностей участников
Расположение: корень проекта (коммитится в репозиторий)
Участники меняют email-адреса, используют разные имена на разных машинах или делают коммиты до правильной настройки Git. .mailmap позволяет канонизировать эти идентичности в истории вашего проекта.
Jane Smith <jane@company.com> <jane@oldmail.com>
Команды вроде git shortlog и git log будут отражать исправленную идентичность без изменения базовой истории коммитов. Эта функция особенно полезна для open-source проектов и долгоживущих репозиториев, где идентичности участников эволюционируют со временем. Формат и поведение описаны в официальной документации mailmap.
Заключение
Эти пять файлов Git dotfiles — .gitconfig, .gitignore, .gitattributes, .git-blame-ignore-revs и .mailmap — каждый решает отдельную проблему в реальных рабочих процессах разработки. Они не просто о личных предпочтениях. Несколько из них должны быть закоммичены непосредственно в ваш репозиторий, где они улучшают опыт для каждого участника команды. Начните с тех, которые решают ваши наиболее насущные проблемы, и ваш рабочий процесс Git станет заметно чище.
Часто задаваемые вопросы
Добавление файла в .gitignore только предотвращает отслеживание Git новых неотслеживаемых файлов. Чтобы прекратить отслеживание файла, который уже был закоммичен, выполните git rm --cached, за которым следует имя файла. Это удалит его из индекса без удаления из вашей рабочей директории. После этого закоммитьте изменение, и правило игнорирования будет применяться в дальнейшем.
Глобальный файл gitignore, настроенный через core.excludesFile в вашем .gitconfig, применяет правила игнорирования ко всем репозиториям на вашей машине. Он идеален для артефактов редактора и файлов, генерируемых ОС. .gitignore на уровне проекта коммитится в репозиторий и делится со всеми коллегами. Используйте его для исключений, специфичных для проекта, таких как вывод сборки или директории зависимостей.
Да. Git требует полные 40-символьные SHA коммитов в файле .git-blame-ignore-revs. Сокращённые хеши не будут работать и вызовут ошибки при выполнении git blame. Вы можете получить полный SHA любого коммита, используя git log или git rev-parse, за которым следует короткий хеш.
Нет. Файл .mailmap не переписывает и не изменяет никакие коммиты. Он только изменяет то, как имена участников и email-адреса отображаются в выводе команд вроде git shortlog и git log. Базовые объекты коммитов остаются неизменными. Это чисто косметическое сопоставление, которое нормализует отображение идентичностей в отчётах и статистике.
Understand every bug
Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.