Какова лучшая стратегия обработки CRLF (возврат каретки, подача линии) с Git?
Я попытался зафиксировать файлы с crlf-конечными строками, но это не удалось.
Я провел целый рабочий день на своем компьютере с Windows, пробуя разные стратегии, и был почти нарисован, чтобы перестать пытаться использовать Git и вместо этого попробовать ртутный.
пожалуйста, поделитесь только одной лучшей практикой за ответ.
9 ответов
почти четыре года после того, как я задал этот вопрос, я, наконец, найдено ответ, который полностью удовлетворяет меня!
смотрите подробности в github: помогите's, чтобы работа с окончаниями строк.
Git позволяет установить свойства окончания строки для РЕПО напрямую с помощью текстовый атрибут в
.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 files для самых популярных языков программирования. Полезно, чтобы вы начали.
после того как вы создали или изменили свои .gitattributes
, вы должны выполнить раз и навсегда окончание строки повторная нормализация.
отметим, что GitHub Desktop приложение может предложить и создать .gitattributes
файл после открытия git repo вашего проекта в приложении. К попробуйте это, нажмите значок шестеренки (в правом верхнем углу) > Настройки репозитория ... > Окончания строк и атрибуты. Вам будет предложено добавить рекомендуемое .gitattributes
и если вы согласны, приложение также выполнит нормализацию всех файлов в вашем репозитории.
наконец, следите за концом вашей линии статьи предоставляет больше фона и объясняет, как Git эволюционировал по текущим вопросам. Я считаю это требуются чтение.
вероятно, в вашей команде есть пользователи, которые используют EGit или JGit (такие инструменты, как Eclipse и TeamCity) для фиксации своих изменений. Тогда вам не повезло, как объяснил @gatinueta в комментариях к этому ответу:
этот параметр не удовлетворит вас полностью, если у вас есть люди, работающие с Egit или JGit в вашей команде, так как эти инструменты будут просто игнорировать .gitattributes и счастливо проверять файлы CRLF https://bugs.eclipse.org/bugs/show_bug.cgi?id=342372
один трюк может заключаться в том, чтобы заставить их совершить свои изменения в другом клиенте, скажем SourceTree. Наша команда тогда предпочла этот инструмент Eclipse EGit для многих случаев использования.
кто сказал, что программное обеспечение легко? :-/
не конвертировать окончания строк. Это не работа VCS интерпретировать данные - просто хранить и версировать их. В любом случае, каждый современный текстовый редактор может читать оба вида окончаний строк.
вы почти всегда хотите autocrlf=input
Если вы действительно знаете, что вы делаете.
дополнительная информация ниже:
это должно быть либо
core.autocrlf=true
Если вам нравится DOS окончание илиcore.autocrlf=input
Если вы предпочитаете unix-newlines. В обоих случаях ваш репозиторий Git будет есть только LF, и это правильно. Единственный аргументcore.autocrlf=false
Это автоматическое эвристика может неправильно обнаружить некоторый двоичный файл как текст и тогда ваша плитка будет испорченный. Так, была введена, чтобы предупредить пользователя, если изменение бесповоротном происходит. На самом деле, есть два возможности необратимых изменений-смешанные строка-окончание в текстовом файле, в этой нормализации желательно, чтобы это предупреждение можно было проигнорировать, или (очень маловероятно), что Git неправильно обнаружил ваш двоичный файл в виде текста. Затем вам нужно использовать атрибуты для сообщить git, что этот файл является двоичным.
вышеуказанный абзац был первоначально вытащен из нить на gmane.org но с тех пор все пошло наперекосяк.
две альтернативные стратегии для сделать последовательную о линейных окончаниях в смешанных средах (Microsoft + Linux + Mac):
А. Глобальные для всех репозиториев Setup
1) преобразование все в один формат
find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'
2) установить core.autocrlf
to input
в Linux / UNIX или true
на MS Windowns (репозиторий или глобальный)
git config --global core.autocrlf input
3) [ опционально ] набор core.safecrlf
to true
(остановить) или warn
(петь:) чтобы добавить дополнительную защиту сравнения, если обратное преобразование новой строки приведет к тому же файлу
git config --global core.safecrlf true
Или на установку репозитория
1) преобразование все в один формат
find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'
2) Добавить .gitattributes
файл в ваш репозиторий
echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'
не беспокойтесь о своих двоичных файлах - ГИТ должен быть достаточно умен.
попробуйте установить конфигурации true
. Также посмотрите на .
на самом деле это звучит как core.safecrlf
может быть уже установлен в вашем репозитории, потому что (акцент мой):
если это не относится к текущей настройке core.autocrlf, git отклонит файл.
если это так, то вы можете проверить, что ваш текстовый редактор настроен на использование окончаний строк последовательно. Скорее всего, вы столкнетесь с проблемами, если текстовый файл содержит смесь окончаний строк LF и CRLF.
наконец, я чувствую, что рекомендация просто "использовать то, что вам дано" и использовать LF-строки в Windows вызовет больше проблем, чем решит. У Git есть вышеуказанные варианты, чтобы попытаться разумно обрабатывать окончания строк, поэтому имеет смысл их использовать.
используя core.autocrlf=false
остановил все файлы от пометки обновляется, как только я проверил их в моем Visual Studio 2010. Другие два члена команды разработчиков также используют системы Windows, поэтому смешанная среда не вступила в игру, но настройки по умолчанию, которые пришли с репозиторием, всегда отмечали все файлы как обновленные сразу после клонирования.
Я думаю, суть в том, чтобы найти, какая настройка CRLF работает для вашей среды. Тем более, что во многих других репозиториях на наших Linux-боксах настройка autocrlf = true
дает лучшие результаты.
20+ лет спустя и мы все еще имеем дело с линией, заканчивающийся различия между ОС... печальный.
это два варианта для окна и Visual Studio пользователи, которые разделяют код с Mac или Linux пользователи. Для расширенного объяснения прочитайте руководство gitattributes по.
* text=auto
в вашем РЕПО добавить:
* text=auto
это нормализует все файлы с помощью LF
окончание строки в репо.
и в зависимости от вашего операционная система (core.eol
настройка), файлы в рабочем дереве будут нормализованы до LF
для систем на базе Unix или CRLF
для систем Windows.
это конфигурация, которая Microsoft .NET использование РЕПО.
пример:
Hello\r\nWorld
будет нормализован в репо всегда как:
Hello\nWorld
при оформлении заказа рабочее дерево в Windows будет преобразовано в:
Hello\r\nWorld
при оформлении заказа, рабочее дерево в Mac будет оставлен как:
Hello\nWorld
Примечание: Если ваше РЕПО уже содержит файлы, не нормализованные,
git status
покажет эти файлы, а полностью изменен в следующий раз вы сделаете какие-либо изменения на них, и это может быть боль для других пользователей, чтобы позже объединить свои изменения. См.обновление репозитория после изменения окончаний строк для получения дополнительной информации.
ядра.autocrlf = true
если text
не указано в .gitattributes
файл, Git использует core.autocrlf
переменная конфигурации, чтобы определить, должен ли файл быть преобразован.
для пользователей Windows, git config --global core.autocrlf true
это идеальный вариант, потому что:
- файлы нормализуются до
LF
символы перевода строки только при добавлении РЕПО. Если в репо есть файлы, которые не нормализованы, этот параметр их не коснется. - все текстовые файлы преобразуются в
CRLF
окончание линии в работе справочник.
проблема с этим подходом заключается в том, что:
- если вы являетесь пользователем Windows с
autocrlf = input
, вы увидите кучу файлов сLF
линия окончаний. Не представляет опасности для остальной команды, потому что ваши коммиты все равно будут нормализованы с помощьюLF
линия окончаний. - если вы являетесь пользователем Windows с
core.autocrlf = false
, вы увидите кучу файлов сLF
окончание строки, и вы можете ввести файлы сCRLF
концы строк в РЕПО. - большинство пользователей Mac используют
autocrlf = input
и может получить файлыCRLF
окончания файлов, вероятно, от пользователей Windows сcore.autocrlf = false
.
это просто решение устранение:
в обычных случаях используйте решения, поставляемые с git. Они отлично работают в большинстве случаев. Force to LF, если вы разделяете разработку в системах на базе Windows и Unix, установив .gitattributes по.
в моем случае было >10 программистов, разрабатывающих проект в Windows. Этот проект был зарегистрирован в CRLF и не было возможности заставить LF.
некоторые настройки были внутренне записаны на моей машине без какого-либо влияния на формат LF; таким образом, некоторые файлы были глобально изменены на LF при каждом небольшом изменении файла.
мое решение:
ОС Windows-Машинам: Пусть все как есть. Не заботьтесь ни о чем, так как вы являетесь разработчиком windows lone wolf по умолчанию, и вам нужно обращаться так: "нет другой системы в широком мире, это это?"
Unix-Машины
-
добавьте следующие строки в конфигурацию . Эта команда перечисляет все измененные (т. е. измененные/новые) файлы:
lc = "!f() { git status --porcelain \ | egrep -r \"^(\?| ).\*\(.[a-zA-Z])*\" \ | cut -c 4- ; }; f "
-
преобразовать все эти изменить файлы в формате dos:
unix2dos $(git lc)
-
дополнительно ...
создать git крючком для этого действия, чтобы автоматизировать этот процесс
-
используйте params и включите его и измените
grep
функция для соответствия только определенным именам файлов, например:... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
-
Не стесняйтесь, чтобы сделать его еще более удобным, используя дополнительный ярлык:
c2dos = "!f() { unix2dos $(git lc) ; }; f "
... и огонь преобразованные вещи, введя
git c2dos
Я потратил часы, чтобы придумать лучшее возможное использование .gitattributes
, чтобы наконец понять, что я не могу на это рассчитывать.
К сожалению, пока существуют Редакторы на основе JGit (которые не могут обрабатывать .gitattributes
правильно), безопасное решение-заставить LF везде, даже на уровне редактора.
использовать следующий anti-CRLF
дезинфицирующих средств.
клиенты windows/linux:
core.autocrlf=input
совершено
.gitattributes
:* text=auto eol=lf
-
совершено
.editorconfig
(http://editorconfig.org/), который является своего рода стандартизированным форматом, в сочетании с плагинами редактора:
--- обновление ---
даже если вы не хотите использовать выше стратегия,следующая команда - ваш друг (Примечание: на клиентах Windows работает только через git-bash
и на клиентах Linux только при компиляции с использованием --with-libpcre
на ./configure
).
# Print all files that have been committed with CRLF (more correctly that contain CR), so that you normalize them.
git grep -I --files-with-matches --perl-regexp '\r' HEAD
один болезненный пример:
netbeans 8.2 (на windows), будет ошибочно фиксировать все текстовые файлы с CRLFs на репо, если вы явно set core.autocrlf
как глобальный. Это противоречит стандартному поведению клиента git и вызывает множество проблем позже, при обновлении / слиянии. Это то, что делает файлы отображаются по-разному (хотя это не так) даже когда вы вернетесь.
Такое же поведение в NetBeans происходит, даже если вы добавили правильно .gitattributes
в проект.
используя приведенную выше команду после фиксации, по крайней мере, поможет вам определить, есть ли у вашего git repo строка окончание проблем.