Подождите редактировать

Вы написали тестовое, выложили на гитхаб и обратно спуллили. А оно не работает.

Шизофренический обратный пулл

Сделала тестовое, рабочее, выложила на гитхаб, стёрла репозиторий в локальном компьютере — я знатный перфекционист, ну и вот чтобы не перепиливать, не допиливать пять тысяч раз.

Дальше решила кое-что там подправить, спуллила проект обратно… а он не работает.

Первые полчаса я думала, что выложила что-то не то. Что перепутала ветку. Пять раз проверила код. Пошла налила себе чаю. Вернулась к компьютеру. Было отчаянно нервно — я же уже успела послать это тестовое на проверку.

Дальше взяла себя в руки, стала искать ошибку — в коде, конечно. Друг мой Вар Дамп помог от души… Мы обнаружили следующее.

Тестовое читает csv файл, строку за строкой. Что-то там с этими строками дальше делает. В частности, заменяет в них «\n» на пустые строки. И это вот поломалось. Именно это место после обратного пулла стало ошибочным.

Я заменила в коде внутри str_replace(«\n», …) «\n» на PHP_EOL, и всё заработало снова.

Так в чём же была проблема

В разных ОС по-разному устроены концы строчек в файлах. Где-то будет просто LF, где-то — CRLF. В «Git для профессионального программиста» Чакон и Штрауб пишут следующее:

С этой ситуацией Git справляется, автоматически конвертируя окончания строк типа CRLF в тип LF в момент индексирования файла и производя обратное преобразование при выгрузке кода из репозитория в файловую систему. Данную функциональность инициирует параметр core.autocrlf. В операционной системе Windows присвоение этому параметру значения true преобразует при выгрузке кода концы строк типа LF в тип CRLF:

$ git config -g core.autocrlf true

Я работаю в Windows, и у меня это — true. Он такой по умолчанию: ещё вчера я вообще не знала про этот параметр.

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

$ git config -g core.autocrlf false

Цитаты были из главки про «Форматирование и пробелы» в главе/части «8. Настройка системы Git».

Выводы

Собственно, я многократно видела эти бегущие строки при работе с Git, про «что-то там с LF и CRLF». Но мне и в голову не приходило, что с этим может быть связано появление ошибки в работающем коде на РНР после применения к нему Git.

Точнее, что инструменты как таковые могут внести ошибку. И даже не в код, а, например, в исходники — как в моём случае. Файл .csv из zip-папки с тестовым изменился именно после проезда через гитхаб.

Код проекта может быть не виноват. И не спешите его редактировать — может быть, дело не в нём, а в истории жизни вашего файла с данными. Где побывали данные между их обработкой вчера (тогда у вас всё срослось) и сегодня (когда всё внезапно сломалось).

Уточню, что тестовое было сравнительно кратким, и выложила я его в гит одним махом — по завершении. При написании кода гит в папке просто отсутствовал, коммитов не было. Если бы были, конечно, ошибка бы вышла раньше.