Скотт Чакон - 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 как сравнивать бинарные файлы, настраивать фильтры добавления или извлечения данных из репозитория. В этом разделе вы узнаете о некоторых атрибутах, которые можно установить для заданных путей в вашем проекте и рассмотрите несколько практических примеров.