Я потратил часы, чтобы придумать наилучшее возможное использование .gitattributes, чтобы наконец понять, что не могу на это рассчитывать.
К сожалению, пока существуют редакторы на основе JGit (которые не могут правильно обрабатывать .gitattributes), безопасным решением является принудительное использование LF везде, даже на уровне редактора.
Используйте следующие anti-CRLF дезинфицирующие средства.
клиенты Windows / Linux: core.autocrlf=input
совершено .gitattributes: * text=auto eol=lf
совершено .editorconfig (http://editorconfig.org/), что является своего рода стандартным форматом в сочетании с плагинами редактора:
--- ОБНОВЛЕНИЕ 2 ---
В большинстве случаев сбои клиента git будут работать. Даже если у вас есть только клиенты Windows, только клиенты Linux или оба. Это:
- windows:
core.autocrlf=true означает преобразование строк в CRLF при оформлении заказа и преобразование строк в LF при добавлении файлов.
- linux:
core.autocrlf=input означает, что не следует преобразовывать строки при извлечении (нет необходимости, поскольку файлы должны быть зафиксированы с помощью LF) и преобразовывать строки в LF (при необходимости) при добавлении файлов.
Свойство может быть установлено в разных областях. Я бы предложил явно установить в области действия --global, чтобы избежать некоторых проблем IDE, описанных в конце.
git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf
Также я бы настоятельно не рекомендовал использовать git config --global core.autocrlf false (в случае, если у вас есть клиенты только с Windows) в отличие от того, что предлагается git документация . Установка в false приведет к фиксации файлов с CRLF в репо. Но на самом деле нет причин. Вы никогда не знаете, нужно ли вам делиться проектом с пользователями Linux. Кроме того, это один дополнительный шаг для каждого клиента, который присоединяется к проекту, вместо использования значений по умолчанию.
Теперь для некоторых особых случаев файлов (например, *.bat *.sh), для которых вы хотите, чтобы они были извлечены с помощью LF или CRLF, вы можете использовать .gitattributes
Подводя итог для меня, лучшая практика это:
- Убедитесь, что каждый недвоичный файл фиксируется с помощью LF в git repo (поведение по умолчанию).
- Используйте эту команду, чтобы убедиться, что ни один файл не зафиксирован с помощью CRLF:
git grep -I --files-with-matches --perl-regexp '\r' HEAD ( Примечание: на клиентах Windows работает только через git-bash и на клиентах Linux только в том случае, если скомпилировано с использованием --with-libpcre в ./configure).
- Если вы нашли такие файлы, выполнив приведенную выше команду, исправьте их.
- Использовать только минимум
.gitattributes
- Поручите пользователям установить для
core.autocrlf, описанного выше, его значения по умолчанию.
- Не рассчитывайте 100% на наличие
.gitattributes. git-клиенты IDE могут игнорировать их или обращаться с ними по-разному.
Как уже было сказано, некоторые вещи могут быть добавлены в атрибуты git:
# Always checkout with LF
*.sh text eol=lf
# Always checkout with CRLF
*.bat text eol=crlf
Я думаю, что некоторые другие безопасные опции для .gitattributes вместо использования автоопределения для двоичных файлов:
-text (например, для файлов *.zip или *.jpg: не будет рассматриваться как текст. Таким образом, преобразование в конце строки не будет предприниматься. Различия могут быть возможны с помощью программ преобразования) text !eol (например, для *.java, *.html: рассматривается как текст, но предпочтение стиля eol не задано. Поэтому используется настройка клиента.) -text -diff -merge (например, для *.hugefile: не обрабатывается как текст. Дифференцирование / объединение невозможно)
--- ПРЕДЫДУЩЕЕ ОБНОВЛЕНИЕ ---
Один болезненный пример клиента, который будет фиксировать файлы неправильно:
netbeans 8.2 (в windows) будет некорректно фиксировать все текстовые файлы с CRLF, если только не имеет явно , устанавливающего core.autocrlf как глобальное . Это противоречит стандартному поведению клиента git и вызывает много проблем позже при обновлении / слиянии. Это то, из-за чего некоторые файлы выглядят по-разному (хотя это не так) даже при возврате .
Такое же поведение в netbeans происходит, даже если вы добавили правильный .gitattributes в свой проект.
Использование следующей команды после фиксации, по крайней мере, поможет вам определить, есть ли у вашего git-репо проблемы с окончанием строки: git grep -I --files-with-matches --perl-regexp '\r' HEAD