Лучшие практики для кросс-платформенной конфигурации git?

Контекст

Некоторые файлы конфигурации моего приложения хранятся в репозитории git для удобства совместного использования на нескольких машинах и на нескольких платформах. Среди этих файлов конфигурации есть .gitconfig, который содержит следующие настройки для обработки символов перевода строки возврата каретки.

[core]
    autocrlf = true
    safecrlf = false

Проблема

Эти настройки также применяются на платформе GNU / Linux, что вызывает неясные ошибки.

Вопрос

Каковы некоторые передовые методы работы с этими различиями в файлах конфигурации, специфичными для платформы?

Предложенное решение

Я понимаю, что эта проблема может быть решена путем создания ветки для каждой платформы и сохранения общих вещей в master и слияния с ветвью платформы, когда master движется вперед. Мне интересно, есть ли какие-нибудь более простые решения этой проблемы?


git git-config
person Community    schedule 25.02.2010    source источник
comment
Связанный вопрос о концах строк и git: stackoverflow.com/questions/1249932/   -  person sleske    schedule 23.01.2012

Ответы (3)


arrow_upward
36
arrow_downward

Я подробно рассмотрел этот тип настройки конфигурации (crlf) в вопросе:
распространение конфигурации git с кодом.

Вывод был такой:

*.java +crlf
*.txt +crlf
...
  • избегайте любого преобразования файлов, которые в нем не нуждаются, из-за различных побочных эффектов такого преобразования для слияний, git status, среды оболочки и svn import (см. "распространение конфигурации git с кодом" для ссылок и справочных материалов).
  • по возможности избегайте любых crlf преобразований.

Теперь, что касается конкретной проблемы настроек для каждой платформы, ветвление не всегда является правильным инструментом, особенно для данных, не связанных с программой (т. Е. Эти настройки не связаны с тем, что вы разрабатываете, а только для VCS, хранящая историю вашего развития)

Как указано в вопросе Git: как поддерживать две ветви проекта и объединять только общие данные?:

ваша жизнь будет намного проще, если вы поместите системно-зависимый код в разные каталоги и будете иметь дело с межплатформенными зависимостями в системе сборки (Makefiles или что-то еще, что вы используете).

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

person Community    schedule 02.03.2010

arrow_upward
63
arrow_downward

Никогда не включайте autocrlf, это не вызывает ничего, кроме головной боли и печали.

Нет оправдания использованию \r\n в Windows, все достойные редакторы (по определению) могут справиться с \n.

person Community    schedule 02.03.2010
comment
несколько примеров головной боли и печали были бы отличным дополнением к этому ответу. - person naught101; 23.05.2012
comment
meh - большинство редакторов / могут / обрабатывать только \ n, но по умолчанию - окончания строк платформы, как они должны. - person Dustin Getz; 28.09.2012
comment
@ naught101, если вы работаете с другими разработчиками и не все используете одну и ту же настройку autocrlf, вы можете столкнуться с множеством конфликтов слияния с файлами / изменениями, которые на самом деле не должны конфликтовать, просто потому, что окончания строк разные . Это особенно опасно в связи с тем, что Git по умолчанию автоматически выполняет слияния, которые считает успешными, и потому, что редакторы различий могут быть настроены на обработку пробелов как несущественных. Плохая или несуществующая проверка кода вашей командой разработчиков может привести к тому, что вы снова введете исправленные ошибки / вызовете опасные регрессии кода. - person ; 11.10.2012
comment
вы можете изменить autocrlf с помощью этой команды git config --global core.autocrlf false - person matthaeus; 30.10.2014
comment
Я опаздываю, но у меня есть пример - Cygwin не может обрабатывать окончания CRLF в сценариях оболочки. Обычно это нормально, но когда этот сценарий является сценарием сборки для половины проектов команды ... много головной боли от людей, которые думают, что система сборки сломана или сборка некорректна, когда они просто забыли запустить Dos-to- Скрипт Unix. Наконец изменил настройки репо, чтобы этого не произошло. - person Jeutnarg; 04.08.2016
comment
Создание docker-образов и любой оболочки Linux или DevOps имеет множество головных болей. - person Giovanni Silva; 27.02.2019

arrow_upward
-3
arrow_downward

Я думаю, у вас должен быть .gitconfig в зависимости от операционной системы, которую использует пользователь. Пользователям Windows вообще не нужен autocrlf, в отличие от пользователей Linux. Например. сохраните текстовые файлы с помощью crlf и пусть Git автоматически конвертирует файлы туда и обратно для пользователей Linux.

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

person Community    schedule 25.02.2010
comment
Окончания файлов linux являются значениями по умолчанию. Это норма для репозиториев git. Таким образом, файлы уже имеют правильный формат для пользователей Linux. Ваша точка зрения обратная. - person scott m gardner; 17.01.2018