Как сравнить две версии текста по строкам

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

В упражнении используются две версии Markdown с расписанием кружка. Нужно найти изменение времени начала и понять, затронуто ли требование к подготовке. При этом не нужно сохранять файлы в Git и менять историю проекта. Если команда Git уже установлена, достаточно режима сравнения двух обычных файлов. Подойдёт и графический редактор, который умеет показать сравнение, но ниже разбирается текстовый вывод.

Подготовьте две независимые копии

Поместите в учебный каталог schedule-before.md и schedule-after.md. Откройте оба файла простым редактором и убедитесь, что они читаются. В первой версии пусть строка выглядит как Начало в 18:30. Во второй поставьте Начало в 19:00 и добавьте требование принести лист с измерениями. Эти данные вымышлены. Для рабочего документа выберите имена, которые однозначно показывают, что было до и после.

Не сравнивайте две вкладки, которые смотрят на один и тот же файл. Часто путь меняется неявно, если редактор автоматически сохранил материал. Проверьте расположение и дату каждого экземпляра. Если исходник в облаке, сначала получите экспорт обеих версий и зафиксируйте, какой соответствует какому снимку. Для текстового сравнения используйте файлы одного типа и сопоставимой кодировки.

Запустите сравнение без репозитория

В терминале из учебного каталога выполните команду. --no-index просит Git сравнить два пути на диске. -- отделяет параметры от имён файлов.

git diff --no-index -- schedule-before.md schedule-after.md

Команда читает оба файла. Она не добавляет их в репозиторий и не применяет показанные изменения. У сравнения с --no-index код завершения 1 может означать, что найдены различия. Это штатный результат для двух различающихся файлов. Сообщение о недоступном пути или другом сбое следует читать отдельно.

Если вывода много, терминал может открыть его в постраничном просмотрщике. Для выхода обычно достаточно q, если используется стандартный просмотрщик Git. Команду можно повторить после уточнения файлов. Не копируйте её вывод в общедоступное место, если тексты содержат закрытую информацию.

Прочитайте один фрагмент внимательно

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

Длинная перестановка текста может выглядеть как удаление в одном месте и добавление в другом, даже если слова совпадают. Поэтому оцените положение нового блока и проверьте, не исчез ли он из нужного раздела. Изменения в Markdown важны и на уровне символов. Отступ может превратить абзац во вложенный список, а лишний пробел или пустая строка могут повлиять на отображение. Цвет подсказок помогает, но ориентироваться нужно на знаки и содержание.

Отделите шум от правок

Если почти каждая строка помечена изменённой, сначала проверьте окончания строк и кодировку. Файл мог быть пересохранён на другой системе. Сравните несколько строк вручную. Для уточняющего просмотра Git поддерживает параметры игнорирования некоторых изменений пробелов. Используйте такой режим как второй взгляд, когда хотите понять, что скрыто за шумом. Не заменяйте им основную проверку Markdown или конфигурации, где пробелы могут иметь значение.

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

Составьте заметку для согласования

Запишите каждое смысловое изменение простой фразой и добавьте место в документе. Например, «в разделе Расписание время начала перенесено с 18:30 на 19:00» и «в разделе Подготовка появился лист с измерениями». Если изменение выглядит случайным, сформулируйте вопрос вместо автоматического отката. Сохраните оба экземпляра, пока не согласована итоговая версия.

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

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

Для контрольной сверки сохраните список правок в отдельной заметке с датой и именами файлов. По этой записи другой редактор сможет повторить сравнение и увидеть те же изменения.

Источники

• Документация Git: git diff и сравнение файлов без индекса