Скотт Чакон - Pro Git

Те, что включены по умолчанию - это blank-at-eol, что ищет пробелы в конце строки; blank-at-eof, что ищет пробелы в конце файла; и space-before-tab, что ищет пробелы перед символом табуляции в начале строки.

Те, что выключены по умолчанию - это indent-with-non-tab, что ищет строки с пробелами вначале вместо символа табуляции (и контролируется настройкой tabwidth); tab-in-indent, что ищет символы табуляции в отступах в начале строки; и cr-at-eol, которая указывает Git на валидность наличия CR в конце строки.

Указав через запятую значения для настройки core.whitespace, можно сказать Git какие из этих опций должны быть включены. Чтобы отключить ненужные проверки, достаточно удалить их из строки значений или поставить знак - перед каждой из них. Например, чтобы включить все проверки, кроме cr-at-eol, выполните команду:

$git config --global core.whitespace \

trailing-space,space-before-tab,indent-with-non-tab

Git будет искать указанные проблемы при выполнении команды git diff и пытаться подсветить их, чтобы вы могли исправить их перед коммитом. Так же эти значения будут использоваться во время применения патчей командой git apply. При применении патчей, можно явно указать Git информировать вас в случае нахождения проблем с пробелами:

$git apply --whitespace=warn

Так же можо указать Git автоматически исправлять эти проблемы перед применением патча:

$git apply --whitespace=fix

Эти настройки так же применяются при выполнении команды git rebase. Если проблемные пробелы попали в коммит, но ещё не отправлены в удаленную ветку, можно выполнить git rebase --whitespace=fix для автоматического исправления этих проблем.

Для серверной части Git не так много настроек, но есть несколько интересных, на которые стоит обратить внимание.

Git способен убедиться, что каждый объект, отправленный командой push, валиден и соответствует своему SHA-1 хэшу. По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев. Вы можете включить проверку консистентности объектов для каждой операции отправки, установив значение receive.fsckObjects в true:

$git config --system receive.fsckObjects true

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

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

Для запрета перезаписи истории установите receive.denyNonFastForwards:

$git config --system receive.denyNonFastForwards true

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

Политику denyNonFastForwards можно обойти, удалив ветку и создав новую с таким же именем. Для предотвращения этого, установите receive.denyDeletes в значение true:

$git config --system receive.denyDeletes true

Эта команда запретит удаление веток и тэгов всем пользователям. Чтобы удалить ветку, придётся удалить все соответствующие ей файлы на сервере вручную. Куда более интересный способ - это настроить права пользователей, с ним вы познакомитесь в разделе An Example Git-Enforced Policy.

Некоторые из настроек могут быть применены к директории, поэтому Git применят их только к поддиректориям или набору файлов. Настройки, зависящие от пути, называются атрибутами и могут быть установлены либо в файле .gitattributes в любой из директорий проекта (обычно, в корневой директории), либо в файле .git/info/attributes, если вы не хотите хранить их в репозитории вместе с вашим проектом.

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

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

Некоторые файлы выглядят как текстовые, но работать с ними нужно как с бинарными данными. Например, на Mac в Xcode проекте содержится файл с расширением .pbxproj, который генерируется IDE, содержит различные настройки проекта и сохраняется в формате JSON (текстовое представление Javascript данных). Технически - это текстовый файл (потому как все данные в UTF-8), фактически - легковесная база данных; отслеживание изменений в нём бесполезно, а слияние изменений - сделанных двумя людьми - невозможно, поэтому вы вряд ли захотите обрабатывать его как текстовый файл. Файл предназначен для чтения машиной, а не человеком. Вот почему его следует рассматривать как бинарный.

Чтобы Git начал обрабатывать все pbxproj файлы как бинарные, добавьте в файл .gitattributes следующую строку:

*.pbxproj binary

Теперь, Git не будет конвертировать или исправлять CRLF в этом файле; не будет пытаться определить изменения или выводить их на экран при выполнении команд git show или git diff.

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

Этот подход решает одну из самых досадных проблем, известных человечеству: контроль версий документов Microsoft Word. Все уже знают, что Word - самый ужасный редактор из всех, но, как ни странно, продолжают его использовать. Если вы хотите контролировать версии документов Word, то поместите их в Git репозиторий и периодически делайте коммиты; но как это решает проблему? Если вы просто выполните команду git diff, то увидите следующее: