Я спробував ввести файли з рядками, що закінчуються CRLF, але це не вдалося.

Я провів цілий робочий день на своєму комп’ютері Windows, пробуючи різні стратегії, і майже не звернувся до спроби використовувати Git і замість цього спробувати Mercurial .

Будь ласка, поділіться лише однією найкращою практикою на відповідь.

Майже через чотири роки після того, як я задав це запитання, я нарешті знайшов відповідь, яка мене повністю задовольняє !

Дивіться деталі в github: посібник з довідки щодо роботи із закінченнями рядків .

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 файлів для найпопулярніших мов програмування. Корисно для початку.

Після того, як ви створили або відкоригували свою .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 . Тоді наша команда віддала перевагу цьому інструменту перед Eclipse's EGit у багатьох випадках використання.

Хто сказав, що програмне забезпечення легко? : - /

Не перетворюйте закінчення рядків. Не завдання VCS інтерпретувати дані - просто зберігати та версіювати. Кожен сучасний текстовий редактор в будь-якому випадку може прочитати обидва види закінчень рядків.

Ви майже завжди хочете, autocrlf=inputякщо ви дійсно не знаєте, що робите.

Деякі додаткові контексти нижче:

Це повинно бути або core.autocrlf=trueякщо вам подобається закінчення DOS, або core.autocrlf=inputякщо ви віддаєте перевагу unix-newlines. В обох випадках у вашому сховищі Git буде лише LF, що є правильною справою. Єдиним аргументом core.autocrlf=falseбуло те, що автоматична евристика може неправильно виявити якийсь двійковий файл як текст, і тоді ваша плитка буде пошкоджена. Отже, core.safecrlfбула введена опція, щоб попередити користувача, якщо відбудеться незворотна зміна. Насправді є дві можливості незворотних змін - змішане закінчення рядків у текстовому файлі, при цьому нормалізація бажана, тому це попередження можна ігнорувати, або (дуже малоймовірно), що Git неправильно виявив ваш бінарний файл як текст. Тоді вам потрібно використовувати атрибути, щоб сказати Git, що цей файл є двійковим.

Вищенаведений параграф спочатку був витягнутий з теми на gmane.org, але з тих пір він знизився.

Дві альтернативні стратегії, щоб зрозуміти закінчення рядків у змішаних середовищах (Microsoft + Linux + Mac):

A. Глобальний за допомогою всіх налаштувань сховищ

1) Перетворити все в один формат

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Встановлено core.autocrlfв inputLinux / UNIX або trueв MS Windows (репозиторій або глобальний)

git config --global core.autocrlf input

3) [Необов’язково] встановити core.safecrlfзначення true(для зупинки) або warn(для співу :), щоб додати додатковий захист порівняння, якщо зворотна трансформація нового рядка призведе до того самого файлу

git config --global core.safecrlf true

B. Або за налаштуванням сховища

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'

Не турбуйтеся про свої бінарні файли - Git повинен бути досить розумним щодо них.

Детальніше про змінні safecrlf / autocrlf

Спробуйте встановити параметр core.autocrlfконфігурації на true. Також подивіться на core.safecrlfваріант.

Насправді це здається, що, core.safecrlfможливо, вже встановлено у вашому сховищі, тому що (акцент мій):

Якщо це не так для поточного налаштування core.autocrlf, git відхилить файл .

Якщо це так, можливо, ви захочете перевірити, чи редактор тексту налаштований для послідовного використання закінчень рядків. Ви, ймовірно, зіткнетеся з проблемами, якщо текстовий файл містить суміш закінчень рядків LF та CRLF.

Нарешті, я вважаю, що рекомендація просто "використовувати те, що вам дано" та використовувати завершені рядки LF у Windows, спричинить більше проблем, ніж вирішує. У Git є наведені вище варіанти спробувати обробити закінчення рядків розумним чином, тому є сенс використовувати їх.

Використання core.autocrlf=falseзупинило те, що всі файли не позначалися оновленими, як тільки я перевірив їх у своєму проекті Visual Studio 2010 . Інші два члени команди розробників також використовують системи Windows, так що змішане середовище не вступало в дію, але налаштування за замовчуванням, які поставляються із сховищем, завжди позначали всі файли оновленими одразу після клонування.

Я думаю, що підсумок полягає у пошуку того, що налаштування CRLF працює для вашого середовища. Тим більше, що в багатьох інших сховищах на наших Linux скриньках налаштування autocrlf = trueдають кращі результати.

20+ років потому, і ми все ще маємо справу з відмінностями між операційними системами, що закінчуються ... сумно.

Це два варіанти для користувачів Windows та Visual Studio, які діляться кодом з користувачами Mac чи Linux . Для розширеного пояснення читайте посібник з gitattributes .

* текст = авто

У .gitattributesфайл вашого репо додайте:

*   text=auto

Це нормалізує всі файли із LFзакінченнями рядків у репо.

І залежно від вашої операційної системи ( core.eolналаштування), файли в робочому дереві будуть нормалізовані LFдля систем на базі Unix або CRLFдля систем Windows.

Це конфігурація, яку використовує Microsoft .NET repos.

Приклад:

Hello\r\nWorld

Буде нормалізовано в РЕПО завжди як:

Hello\nWorld

Під час оформлення замовлення робоче дерево в Windows буде перетворено на:

Hello\r\nWorld

Під час оформлення замовлення робоче дерево в Mac залишатиметься як:

Hello\nWorld

Примітка. Якщо ваше репо вже містить файли, не нормалізовані, git statusвони покажуть ці файли як повністю змінені наступного разу, коли ви внесете будь-які зміни на них, і це може зашкодити іншим користувачам пізніше об'єднати свої зміни. Для отримання додаткової інформації див. Оновлення сховища після зміни закінчень рядків .

core.autocrlf = вірно

Якщо 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.

--- ОНОВЛЕННЯ 3 --- (не суперечить ОНОВЛЕННЮ 2)

Враховуючи випадок, що користувачі Windows вважають за краще працювати над, CRLFа користувачі Linux / mac віддають перевагу роботі LFнад текстовими файлами. Надання відповіді з точки зору підтримки репозиторію :

Для мене найкраща стратегія (менше проблем вирішити) є: зберегти всі текстові файли з LFвнутрішнім мерзотником репо , навіть якщо ви працюєте над проектом , вікна-тільки. Потім надайте клієнтам свободу працювати над стилем закінчення рядків за своїм уподобанням за умови, що вони вибирають core.autocrlfзначення властивості, яке буде відповідати вашій стратегії (LF on repo) під час постановки файлів для фіксації.

Постановка - це те, що багато хто плутає, намагаючись зрозуміти, як працюють нові стратегії . Перш ніж вибрати правильне значення для core.autocrlfвластивості, важливо відмовитись від наступних пунктів :

• Додавання текстового файлу до фіксації ( постановка його) - це як копіювання файлу в інше місце всередині .git/підкаталогу з перетвореними закінченнями рядків (залежно від core.autocrlfзначення конфігурації вашого клієнта). Все це робиться на місцях.
• налаштування core.autocrlf- це як відповідь на запитання (точно таке ж питання у всіх ОС):
  • "Чи повинен git-client a. Перетворювати LF-в-CRLF під час перевірки (витягування) репо-зміни змінюється з віддаленого або b. Перетворювати CRLF-в-LF при додаванні файлу для фіксації? " Та можливих відповідей (значень) є:
  • false:" не робити нічого з перерахованого вище ",
  • input:" робити лише б "
  • true: " зробіть a і b "
  • зауважте, що НІМАЄ " робити тільки "

На щастя

• налаштування клієнтських налаштувань git (windows:, core.autocrlf: truelinux / mac:) core.autocrlf: falseбудуть сумісні зі стратегією LF-only-repo .
  Значення : клієнти Windows за замовчуванням перетворюються на CRLF під час перевірки сховища та перетворюються на LF при додаванні для фіксації. А клієнти Linux за замовчуванням не здійснюють ніяких перетворень. Це теоретично зберігає лише ваш репо-ліф.

На жаль:

• Можуть бути клієнти GUI, які не поважають core.autocrlfзначення git
• Можуть бути люди, які не використовують значення, щоб поважати вашу стратегію lf-repo. Наприклад, вони використовують core.autocrlf=falseі додають файл із CRLF для фіксації.

Для виявлення невідкритих текстових файлів ASAP, скоєних вищевказаними клієнтами, ви можете дотримуватися того, що описано в --- оновлення 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, на клієнті, складеному за допомогою: --with-libpcreflag)

А ось заковика: . Я, як репортаж репо, зберігаю git.autocrlf=inputтак, щоб я міг виправити будь-які помилково виконані файли, просто додавши їх знову для фіксації. І я надаю текст фіксації: "Виправлення помилково зафіксованих файлів".

Наскільки .gitattributesце приховано. Я на це не розраховую, тому що є більше клієнтів інтерфейсу, які цього не розуміють. Я використовую його лише, щоб надати підказки для текстових та бінарних файлів, і, можливо, позначити деякі виняткові файли, які повинні скрізь зберігати однакові закінчення рядків:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Питання: Але чому нас взагалі цікавить стратегія обробки нових рядків?

Відповідь: Щоб уникнути фіксації зміни однієї літери, відображайтесь як зміна в 5000 рядків лише тому, що клієнт, який здійснив зміну, автоматично перетворив повний файл з crlf в lf (або навпаки), перш ніж додати його для фіксації. Це може бути досить болісно, коли йдеться про вирішення конфлікту . Або в деяких випадках це може бути причиною необґрунтованих конфліктів.

--- ОНОВЛЕННЯ 2 ---

Параметри git-клієнта працюватимуть у більшості випадків. Навіть якщо у вас є лише клієнти Windows, клієнти лише для Linux або обидва. Це:

• windows: core.autocrlf=true означає перетворити рядки в CRLF під час оформлення каси та перетворити рядки в LF при додаванні файлів.
• linux: core.autocrlf=input означає не конвертувати рядки під час замовлення (не потрібно, оскільки файли очікуються з LF) та перетворювати рядки в LF (якщо потрібно) при додаванні файлів. ( - update3 - : Здається, що це falseза замовчуванням, але знову це нормально)

Властивість можна встановити в різних сферах. Я б запропонував чітко встановити --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

Також я настійно не хочу перешкоджати використанню для Windows 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( Примітка: на вікнах клієнтів працює тільки через git-bashі на Лінукс клієнтів , тільки якщо компілюється з використанням --with-libpcreв ./configure).
• Якщо ви знайдете будь-які такі файли, виконавши вищевказану команду, виправте їх. Це включає в себе (принаймні на Linux):
  • набір core.autocrlf=input( --- оновлення 3 - )
  • змінити файл
  • відновити зміни (файл все ще відображається як змінений)
  • вчинити це
• Використовуйте лише мінімальний мінімум .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 repo проблеми з закінченням рядка: 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

• скоєний .editorconfig( http://editorconfig.org/ ), який є типовим стандартизованим форматом у поєднанні з плагінами редактора:

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Це лише рішення рішення:

У звичайних випадках використовуйте розчини, які постачаються з git. Вони чудово працюють у більшості випадків. Запропонуйте LF, якщо ви поділитесь розробкою в системах на базі Windows та Unix, встановивши .gitattributes .

У моєму випадку було> 10 програмістів, які розробляли проект у Windows. Цей проект був зареєстрований у CRLF, і не було можливості примушувати його до LF.

Деякі налаштування були записані внутрішньо на моїй машині без будь-якого впливу на формат LF; таким чином деякі файли були глобально змінені на LF при кожній невеликій зміні файлу.

Моє рішення:

Windows-машини: Нехай все як є. Дбайте ні про що, оскільки ви розробник Windows "одинокий вовк" за замовчуванням, і вам доводиться поводитися так: "Іншої системи в світі немає, чи не так?"

Unix-машини

1. Додайте наступні рядки до [alias]розділу конфігурації . Ця команда перераховує всі змінені (тобто змінені / нові) файли:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Перетворити всі змінені файли у формат dos:

   unix2dos $(git lc)

3. За бажанням ...

   1. Створіть гачку для цієї дії, щоб автоматизувати цей процес

   2. Використовуйте параметри та включайте її та змінюйте grepфункцію, щоб вона відповідала лише певним іменам, наприклад:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Сміливо зробіть це ще зручнішим, скориставшись додатковим ярликом:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... і запустити перетворений матеріал, набравши текст

      git c2dos