8.2 Настройка Git - Атрибуты Git

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

Разработчики часто хотят использовать разворачивание ключевых слов в стиле SVN или CVS. Основная проблема в Git — это невозможность изменять файлы с информацией о коммите после его совершения, так как Git сначала вычисляет контрольную сумму. Однако, вы можете добавить текст в файл после извлечения и убрать его перед добавлением файла в коммит. Атрибуты Git позволяют это сделать двумя способами.

Для начала, вы можете автоматически добавлять SHA-1-хеш объекта в поле $Id$. Если установить этот атрибут для одного или нескольких файлов, то каждый раз при извлечении ветки Git будет заменять это поле на SHA-1-хеш объекта. Важно заметить, что это SHA-1-хеш не коммита, а самого объекта. Добавьте следующую строку в ваш файл .gitattributes:

Добавьте ссылку на $Id$ в тестовый файл:

При последующих извлечениях Git будет добавлять SHA-1-хеш объекта:

Однако, этот результат имеет ограниченное применение. Если вы использовали подстановку ключевых слов в CVS или Subversion, то вы могли включать метку времени, а SHA-1-хеш не так полезен, потому что вы не можете сказать какой из двух хешей старше, а какой новее просто взглянув на них.

Оказывается, вы можете написать свои фильтры для выполнения подстановок в файлах в момент коммита/извлечения. Эти фильтры называются «clean» и «smudge». В файле .gitattributes вы можете установить фильтр для конкретных путей, а затем указать скрипты для обработки файлов при извлечении («smudge», смотри Фильтр «smudge» применяется при извлечении) и при индексировании («clean», смотри Фильтр «clean» применяется при индексации). С помощью этих фильтров можно делать всевозможные операции.

Исходное сообщение коммита является простым примером как передать весь ваш код на С программе indent перед коммитом. Это можно настроить путём указания фильтра «indent» в файле .gitattributes для файлов *.c.

Затем скажите Git что должен делать фильтр «indent» на стадиях smudge и clean:

В таком случае, Git будет обрабатывать файлы программой indent все файлы по маске *.c перед тем, как добавить их в индекс; и наоборот, обрабатывать эти же файлы программой cat при их извлечении. По сути, программа cat ничего не делает: она возвращает те же данные, что и получает на вход. Указанная комбинация позволяет эффективно обрабатывать файлы с исходным кодом на С программой indent перед коммитом.

Другой интересный пример — это подстановка ключевого слова $Date$ в стиле системы контроля ревизий. Чтобы правильно это реализовать, вам нужен простой скрипт, который получает имя файла, определяет дату последнего коммита и вставляет её в файл. Ниже приведён небольшой пример такого скрипта на Ruby:

Всё, что делает скрипт — это получает дату последнего коммита с помощью команды git log, заменяет результатом все подстроки $Date$ и возвращает итоговый результат; вы можете написать аналогичный скрипт на любом языке. Назовите файл со скриптом, например, expand_date и сохраните в каталоге с программами. Теперь, нужно настроить Git фильтр (назовите его dater) и укажите ему использовать ваш скрипт expand_date при извлечении файлов. Вместе с этим, мы будем использовать регулярное выражение Perl для очистки перед коммитом:

Указанная Perl команда очищает любое значение в строке, где она видит $Date$, чтобы вернуть файл в изначальное состояние. Теперь фильтр готов и вы можете проверить его добавив ключевое слово $Date$ в файл и настроив Git атрибут, чтобы для вашего файла применялся созданный фильтр:

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

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

Атрибуты Git так же позволяют вам делать некоторые интересные вещи при экспорте вашего проекта.

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

Это полезно в случае, когда ветка разошлась или у вас специализированная ветка, при этом вы хотите иметь возможность сливать изменения, но игнорировать определённые файлы. Предположим, что у вас есть файл с настройками базы данных database.xml, содержимое которого в разных ветках отличается, при этом вы хотите сливать изменения из другой ветки не меняя этот файл. Для этого нужно добавить следующий атрибут:

А затем определить фиктивную стратегию слияния ours, выполнив команду:

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

В этом случае файл database.xml всегда остаётся неизменным.