Вы написали тестовое, выложили на гитхаб и обратно спуллили. А оно не работает.
Шизофренический обратный пулл
Сделала тестовое, рабочее, выложила на гитхаб, стёрла репозиторий в локальном компьютере - я знатный перфекционист, ну и вот чтобы не перепиливать, не допиливать пять тысяч раз.
Дальше решила кое-что там подправить, спуллила проект обратно... а он не работает.
Первые полчаса я думала, что выложила что-то не то. Что перепутала ветку. Пять раз проверила код. Пошла налила себе чаю. Вернулась к компьютеру. Было отчаянно нервно - я же уже успела послать это тестовое на проверку.
Дальше взяла себя в руки, стала искать ошибку - в коде, конечно. Друг мой Вар Дамп помог от души... Мы обнаружили следующее.
Тестовое читает 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-папки с тестовым изменился именно после проезда через гитхаб.
Код проекта может быть не виноват. И не спешите его редактировать - может быть, дело не в нём, а в истории жизни вашего файла с данными. Где побывали данные между их обработкой вчера (тогда у вас всё срослось) и сегодня (когда всё внезапно сломалось).
Уточню, что тестовое было сравнительно кратким, и выложила я его в гит одним махом - по завершении. При написании кода гит в папке просто отсутствовал, коммитов не было. Если бы были, конечно, ошибка бы вышла раньше.
