Спустя почти четыре года после того, как я задал этот вопрос, я наконец нашел ответ, который меня полностью устраивает !
Подробности смотрите в github: справочное руководство по
работе с окончаниями строк .
Git позволяет вам установить конечные свойства строки для репо, используя атрибут text в
.gitattributes
файле. Этот файл фиксируется в репозитории и переопределяет core.autocrlf
настройку, позволяя вам обеспечить согласованное поведение для всех пользователей независимо от их настроек git.
И поэтому
Преимущество этого заключается в том, что ваша конечная конфигурация теперь перемещается вместе с вашим хранилищем, и вам не нужно беспокоиться о том, имеют ли соавторы правильные глобальные настройки.
Вот пример .gitattributes
файла
# Auto detect text files and perform LF normalization
* text=auto
*.cs text diff=csharp
*.java text diff=java
*.html text diff=html
*.css text
*.js text
*.sql text
*.csproj text merge=union
*.sln text merge=union eol=crlf
*.docx diff=astextplain
*.DOCX diff=astextplain
# absolute paths are ok, as are globs
/**/postinst* text eol=lf
# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf
Существует удобная коллекция готовых к использованию файлов .gitattributes для самых популярных языков программирования. Это полезно для начала.
После того, как вы создали или скорректировали свою .gitattributes
, вы должны выполнить повторную нормализацию окончаний строки раз и навсегда .
Обратите внимание, что приложение GitHub Desktop может предложить и создать .gitattributes
файл после открытия репозитория Git вашего проекта в приложении. Чтобы попробовать это, щелкните значок шестеренки (в правом верхнем углу)> Настройки репозитория ...> Концы строк и атрибуты. Вам будет предложено добавить рекомендуемые .gitattributes
и, если вы согласны, приложение также выполнит нормализацию всех файлов в вашем хранилище.
Наконец, в статье « Разум в конце своей строки» содержится дополнительная справочная информация и объясняется, как Git развивался в рассматриваемых вопросах. Я считаю это обязательным чтением .
Возможно, в вашей команде есть пользователи, которые используют EGit или JGit (такие инструменты, как Eclipse и TeamCity используют их) для фиксации своих изменений. Тогда вам не повезло, как объясняет @gatinueta в комментариях к этому ответу:
Этот параметр не удовлетворит вас полностью, если в вашей команде есть люди, работающие с Egit или JGit, поскольку эти инструменты будут просто игнорировать .gitattributes и с радостью проверять файлы CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? ID = 342372
Одна хитрость может заключаться в том, чтобы они зафиксировали свои изменения в другом клиенте, скажем SourceTree . В то время наша команда предпочитала этот инструмент EGip для Eclipse во многих случаях.
Кто сказал, что программное обеспечение легко? : - /
.gitattributes
?.gitattributes
GitHub для Windows предлагает для вашего проекта? Я установил GitHub для Windows, запустил версию с графическим интерфейсом и не смог найти ни одной опции, связанной с.gitattributes
предложениями.core.autocrlf = false
- я предпочитаю LF везде, но некоторые инструменты Windows, такие как Visual Studio, настаивают на окончаниях CRLF в определенных файлах (и даже смешивают их в нескольких ..); не жонглирование концов строк - самый безопасный вариант. Если вы знаете, что делаете, я бы, вероятно, использовалcore.autocrlf = input
и сделал бы исключения для проектов в Windows, которые, как вы знаете, чувствительны к окончанию строк. Как отмечают другие, каждый приличный текстовый редактор теперь поддерживает LF-окончания. Я действительно думаю, чтоcore.autocrlf = true
может вызвать больше проблем, чем предотвратить.Не конвертируйте окончания строк. Это не работа VCS, чтобы интерпретировать данные - просто сохраните и версируйте их. Каждый современный текстовый редактор в любом случае может читать оба вида окончаний строк.
источник
Вы почти всегда хотите,
autocrlf=input
если вы действительно не знаете, что делаете.Некоторый дополнительный контекст ниже:
Вышеупомянутый абзац изначально был извлечен из потока на gmane.org, но с тех пор он отключился
источник
core.autocrlf=input
это канонический ответ. Для большинства случаев применения,core.autocrlf=true
иcore.autocrlf=false
чрезмерно усердствовать (... в противоположном , но одинаково ужасных способах, конечно) и , следовательно , по своей природе разрушительный. «Git for Windows» действительно должен был поставляться с «Checkout как есть, фиксировать окончания строк в стиле Unix» (т.е.core.autocrlf=input
) в качестве стратегии по умолчанию для новой строки. Это не так. Так что вот мы здесь - в офигенном 2015 году - до сих пор бесконечно обсуждаем это.Две альтернативные стратегии для согласования окончаний строк в смешанных средах (Microsoft + Linux + Mac):
A. Глобальная настройка для всех репозиториев
1) Конвертировать все в один формат
2) Установите
core.autocrlf
вinput
Linux / UNIX илиtrue
в MS Windows (репозиторий или глобальный)3) [Необязательно] установите
core.safecrlf
вtrue
(чтобы остановить) илиwarn
(чтобы петь :), чтобы добавить дополнительное охранное сравнение, если обратное преобразование новой строки приведет к тому же файлуБ. Или для каждого хранилища
1) Конвертировать все в один формат
2) добавить
.gitattributes
файл в свой репозиторийНе беспокойтесь о ваших двоичных файлах - Git должен быть достаточно умным с ними.
Подробнее о переменных safecrlf / autocrlf
источник
dos2unix
это инструмент командной строки, который в зависимости от системы может потребоваться установить дополнительноdos2unix
- есть риск повреждения,.git/index
и нам не нужно применять его к каждому файлу. Лучше использовать что-то вродеfind ./ -name "*.html"
и указать, к каким файлам вы хотите применить это.find
строк, имейте в виду: то,dos2unix
что поставляется с Git для Windows, имеет своеобразное (IMO идиотское и опасное) поведение без аргументов: вместо перехода на UNIX он переключает формат новой строки (DOS <-> UNIX )Попробуйте установить
core.autocrlf
опцию конфигурации вtrue
. Также посмотрите наcore.safecrlf
вариант.На самом деле это звучит так, как будто это
core.safecrlf
может быть уже установлено в вашем хранилище, потому что (выделение мое):Если это так, то вы можете проверить, что ваш текстовый редактор настроен на последовательное использование концов строк. Скорее всего, вы столкнетесь с проблемами, если текстовый файл будет содержать сочетания концов строк LF и CRLF.
Наконец, я чувствую, что рекомендация просто «использовать то, что вам дано» и использовать строки с ограничением LF в Windows, вызовет больше проблем, чем решит. У Git есть вышеупомянутые опции, чтобы попытаться обработать окончания строк разумным способом, поэтому имеет смысл использовать их.
источник
Использование
core.autocrlf=false
прекратило помечать все файлы как обновленные, как только я проверил их в своем проекте Visual Studio 2010 . Два других члена команды разработчиков также используют системы Windows, поэтому смешанная среда не вступила в игру, но настройки по умолчанию, поставляемые с хранилищем, всегда отмечали все файлы как обновленные сразу после клонирования.Я думаю, суть в том, чтобы найти, какой параметр CRLF работает для вашей среды. Тем более что во многих других репозиториях на наших установках Linux ящики
autocrlf = true
дают лучшие результаты.Спустя 20 с лишним лет, и мы все еще имеем дело с разницей в конце строк между ОС ... печально.
источник
Это две опции для пользователей Windows и Visual Studio, которые делятся кодом с пользователями Mac или Linux . Для более подробного объяснения прочитайте руководство по gitattributes .
* текст = авто
В
.gitattributes
файле вашего репо добавьте:Это нормализует все файлы с
LF
окончаниями строк в репо.И в зависимости от вашей операционной системы (
core.eol
настройки) файлы в рабочем дереве будут нормализованыLF
для системCRLF
на основе Unix или для систем Windows.Это конфигурация, которую используют репозитории Microsoft .NET .
Пример:
Будет нормализовано в репо всегда так:
При оформлении заказа рабочее дерево в Windows будет преобразовано в:
На кассе рабочее дерево в Mac останется как:
core.autocrlf = true
Если
text
в.gitattributes
файле не указано иное, Git используетcore.autocrlf
переменную конфигурации, чтобы определить, нужно ли конвертировать файл.Для пользователей Windows
git config --global core.autocrlf true
это отличный вариант, потому что:LF
окончанию строк только при добавлении в репо. Если в репо есть файлы, которые не нормализованы, этот параметр не коснется их.CRLF
окончания строк в рабочем каталоге.Проблема с этим подходом заключается в том, что:
autocrlf = input
, вы увидите множество файлов сLF
окончаниями строк. Не представляет опасности для остальной части команды, потому что ваши коммиты все равно будут нормализованы сLF
окончанием строки.core.autocrlf = false
, вы увидите группу файлов сLF
окончаниями строк и можете добавить файлы с окончаниямиCRLF
строк в репозиторий.autocrlf = input
и могут получать файлы сCRLF
окончаниями файлов, вероятно, от пользователей Windowscore.autocrlf = false
.источник
git config --global core.autocrl true
. Вы имеете в видуgit config --global core.autocrlf true
.--- ОБНОВЛЕНИЕ 3 --- (не конфликтует с ОБНОВЛЕНИЕМ 2)
Учитывая тот случай, когда пользователи Windows предпочитают работать,
CRLF
а пользователи Linux / Mac предпочитают работатьLF
с текстовыми файлами. Предоставление ответа с точки зрения сопровождающего хранилища :Для меня лучшая стратегия (меньше проблем решить) является: сохранить все текстовые файлы с
LF
внутренним мерзавцем репо , даже если вы работаете над проектом , окна-только. Затем предоставьте клиентам возможность работать со стилем окончания строки по своему усмотрению , при условии, что они выбираютcore.autocrlf
значение свойства, которое будет соответствовать вашей стратегии (LF на репо) при подготовке файлов для фиксации.Постановка - это то, что многие люди путают, пытаясь понять, как работают стратегии новой строки . Важно выбрать следующие моменты, прежде чем выбрать правильное значение для
core.autocrlf
свойства:.git/
подкаталога с преобразованными окончаниями строк (в зависимости отcore.autocrlf
значения в конфигурации клиента). Все это делается локально.core.autocrlf
аналогична предоставлению ответа на вопрос (точно такой же вопрос на всех ОС):false:
"не делай ничего из вышеперечисленного ",input:
" делай только б "true
: " сделать а и б "к счастью
core.autocrlf: true
linux / mac:)core.autocrlf: false
будут совместимы со стратегией LF-only-repo .Значение : клиенты Windows по умолчанию преобразуются в CRLF при извлечении из хранилища и преобразуются в LF при добавлении для фиксации. И клиенты Linux по умолчанию не будут делать никаких преобразований. Это теоретически сохраняет ваш репо только для жизни.
К несчастью:
core.autocrlf
значение gitcore.autocrlf=false
и добавляют файл с CRLF для фиксации.Чтобы обнаружить текстовые файлы не как lf, зафиксированные указанными выше клиентами, вы можете следовать инструкциям, приведенным в --- update 2 ---: (
git grep -I --files-with-matches --perl-regexp '\r' HEAD
на клиенте, скомпилированном с использованием:--with-libpcre
flag)А вот и подвох . Я, как сопровождающий, храню
git.autocrlf=input
репозиторий, чтобы я мог исправить любые ошибочно зафиксированные файлы, просто добавив их снова для фиксации. И я предоставляю текст коммита: «Исправление неверно зафиксированных файлов».Насколько
.gitattributes
это скрыто. Я не рассчитываю на это, потому что есть больше клиентов, которые не понимают этого. Я использую его только для предоставления подсказок для текстовых и двоичных файлов и, возможно, помечаю некоторые исключительные файлы, которые должны везде иметь одинаковые окончания строк:Вопрос: Но почему мы вообще заинтересованы в стратегии обработки новой строки?
Ответ. Чтобы избежать фиксации изменения одной буквы, отображается изменение в 5000 строк только потому, что клиент, выполнивший изменение, автоматически преобразовал полный файл из crlf в lf (или наоборот) перед добавлением его для фиксации. Это может быть довольно болезненным, когда вовлечено разрешение конфликта . Или это может быть в некоторых случаях причиной необоснованных конфликтов.
--- ОБНОВЛЕНИЕ 2 ---
По умолчанию клиент git будет работать в большинстве случаев. Даже если у вас есть только клиенты Windows, только клиенты Linux или оба. Эти:
core.autocrlf=true
означает преобразование строк в CRLF при оформлении заказа и преобразование строк в LF при добавлении файлов.core.autocrlf=input
означает, что не нужно конвертировать строки при оформлении заказа (в этом нет необходимости, поскольку ожидается, что файлы будут зафиксированы с помощью LF), а конвертировать строки в LF (если необходимо) при добавлении файлов. ( - update3 - : кажется, что этоfalse
по умолчанию, но опять же все в порядке)Свойство может быть установлено в разных областях. Я бы предложил явно указать в области
--global
действия, чтобы избежать некоторых проблем IDE, описанных в конце.Также я бы настоятельно не рекомендовал использовать в Windows
git config --global core.autocrlf false
(если у вас есть клиенты только для Windows), в отличие от того, что предлагается для git документации . Установка в false приведет к фиксации файлов с CRLF в репо. Но на самом деле нет причин. Вы никогда не знаете, нужно ли вам делиться проектом с пользователями Linux. Плюс это один дополнительный шаг для каждого клиента, который присоединяется к проекту, вместо использования значений по умолчанию.Теперь для некоторых особых случаев файлов (например
*.bat
*.sh
), которые вы хотите, чтобы они были извлечены с помощью LF или CRLF, вы можете использовать.gitattributes
Подводя итог для меня, лучшая практика :
git grep -I --files-with-matches --perl-regexp '\r' HEAD
( Примечание: на клиентах Windows работает только черезgit-bash
клиентов Linux и только на клиентах Linux, если они скомпилированы с использованием--with-libpcre
in./configure
).core.autocrlf=input
( --- обновление 3 - ).gitattributes
core.autocrlf
описанные выше значения по умолчанию..gitattributes
. git-клиенты IDE могут игнорировать их или обращаться с ними по-разному.Как уже было сказано, некоторые вещи могут быть добавлены в атрибуты git:
Я думаю, что некоторые другие безопасные варианты
.gitattributes
вместо использования автоопределения для двоичных файлов:-text
(например, для*.zip
или*.jpg
файлов: не будет рассматриваться как текст. Таким образом, преобразование в конце строки не будет предприниматься. Различия могут быть возможны через программы преобразования)text !eol
(например , для*.java
,*.html
:.. Лечили как текст, но предпочтение EOL стиль не установлен Так настройка клиента используется)-text -diff -merge
(например, для*.hugefile
: Не обрабатывается как текст. Дифф / слияние невозможно)--- ПРЕДЫДУЩЕЕ ОБНОВЛЕНИЕ ---
Один болезненный пример клиента, который ошибочно фиксирует файлы:
NetBeans 8.2 (на окнах), будет неправильно совершать все текстовые файлы с CRLFs, если вы не в явном виде установить
core.autocrlf
как глобальные . Это противоречит стандартному поведению клиента git и вызывает много проблем позже при обновлении / слиянии. Это то, что заставляет некоторые файлы выглядеть по-разному (хотя это не так), даже когда вы возвращаетесь .Такое же поведение в NetBeans происходит, даже если вы правильно добавили
.gitattributes
в свой проект.Использование следующей команды после фиксации, по крайней мере, поможет вам определить, есть ли у вашего git-репо проблемы с окончанием строки:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
Я потратил часы, чтобы придумать наилучшее из возможных применений.gitattributes
, чтобы наконец понять, что я не могу на это рассчитывать.К сожалению, пока существуют редакторы на основе JGit (которые не могут
.gitattributes
правильно обрабатывать ), безопасное решение состоит в том, чтобы заставить LF везде, даже на уровне редактора.Используйте следующие
anti-CRLF
дезинфицирующие средства.клиенты windows / linux:
core.autocrlf=input
совершено
.gitattributes
:* text=auto eol=lf
commit
.editorconfig
( http://editorconfig.org/ ), который является своего рода стандартизированным форматом в сочетании с плагинами редактора:https://github.com/welovecoding/editorconfig-netbeans/источник
.gitattributes
линией, он имеет непреднамеренный conseques в Git <2.10 см stackoverflow.com/a/29508751/2261442git config --global core.autocrlf false
и рекомендую иметь дело с eol.gitattributes
только в директивах.Это просто обходное решение:
В обычных случаях используйте решения, которые поставляются с git. Они прекрасно работают в большинстве случаев. Принудительно LF, если вы делитесь разработкой в системах на базе Windows и Unix, устанавливая .gitattributes .
В моем случае> 10 программистов разрабатывали проект в Windows. Этот проект был проверен с CRLF, и не было никакой возможности, чтобы заставить LF.
Некоторые настройки были написаны на моем компьютере без какого-либо влияния на формат LF; таким образом, некоторые файлы глобально менялись на LF при каждом небольшом изменении файла.
Мое решение:
Windows-машины: пусть все как есть. Ничего не волнует, так как вы являетесь разработчиком окон «одинокий волк» по умолчанию, и вам приходится обращаться с этим так: «В широком мире нет другой системы, не так ли?»
Unix-машины
Добавьте следующие строки в
[alias]
раздел конфигурации . Эта команда выводит список всех измененных (т.е. измененных / новых) файлов:Преобразуйте все эти измененные файлы в формат DOS:
По выбору ...
Создайте git hook для этого действия, чтобы автоматизировать этот процесс
Используйте params, включите его и измените
grep
функцию, чтобы она соответствовала только определенным именам файлов, например:Не стесняйтесь делать это еще удобнее, используя дополнительные ярлыки:
... и запустить преобразованный материал, набрав
источник