Каждый проект состоит из бесчисленных небольших изменений. Если повезет, они, наконец, сформируют веб-сайт, приложение или какой-либо другой продукт. Ваша система контроля версий отслеживает эти изменения. Но только когда вы поймете, как их читать, вы сможете отслеживать прогресс вашего проекта.
На примере популярной системы контроля версий Git эта статья поможет вам понять эти изменения.
Различия представляют изменения
В управлении версиями различия между одной версией и другой представлены в том, что называется «diff» (или «патч»). Вы столкнетесь с различиями при работе в техническом окружении, таком как командная строка, а также в графических инструментах, таких как «Tortoise Git» (Win) или «Tower» (Mac), и на платформах хостинга кода, таких как «GitHub» . Различия — это наиболее часто используемые методы визуализации изменений.
Давайте научимся читать различия на примере.
Сравненные файлы A / B
В нашем примере diff сравниваются два элемента друг с другом: элемент A и элемент B. Теоретически, A и B могут быть любым файлом. Однако в большинстве случаев вы захотите сравнить один и тот же файл, но в двух разных версиях.
Чтобы установить сцену, вывод diff всегда начинается с объявления, какие файлы представлены «A» и «B».
Метаданные файла
Ниже приведена техническая информация, которая вам понадобится редко: метаданные файла.
Первые две строки представляют объектные хэши (или «идентификаторы») наших двух файлов. В фоновом режиме Git сохраняет не только версии проекта, но и каждый элемент файла как объект. Хеши, подобные представленным здесь, используются для идентификации файла определенной версии.
Наконец, число справа является внутренним идентификатором режима файла; «100644» — это просто «обычный файл», «100755» определяет исполняемый файл, а «120000» — символическую ссылку.
Маркеры для а / б
Чуть позже в выводе отображаются реальные фрагменты изменений. Чтобы можно было определить, из какой версии (A или B), каждому сравниваемому элементу присваивается символ: для версии A используется знак минус («-»), а для «плюс» («+») версия Б.
ломоть
Проверка файла из 10000 строк только с двумя измененными строками была бы утомительным процессом, если бы diff показывал все содержимое файла одновременно. Вместо этого отображаются только те части, которые были фактически изменены. В Git такая часть называется «кусок» (или «кусок»). Фактически измененные строки окружены неизмененными линиями до и после модификации. Они называются «контекстом», потому что они помогают пользователю понять контекст, в котором были сделаны эти изменения.
Заголовок куска
Заголовок предшествует каждому из этих кусков. Первая часть заголовка информирует вас о том, какие строки были затронуты, заключенные в два знака «@» каждая Давайте посмотрим, какие строки были изменены в первом фрагменте нашего примера diff:
- Из файла A (обозначенного «-») извлекаются 6 строк, начиная со строки №. 34
- Из файла B (обозначенного «+») отображаются 8 строк, также начиная со строки №. 34
После закрывающей пары «@@» дается еще один фрагмент контекста: Git пытается отобразить имя метода или другую контекстную информацию о том, откуда этот фрагмент был взят в файле. Однако это зависит от языка программирования и работает не во всех сценариях.
изменения
Чтобы понять изменение, вы должны видеть оба его состояния — до и после изменения. Вот почему Git помечает строки, которые фактически были изменены, знаком «+» или «-»: строка, начинающаяся со знака «-», идет от A, а строка со знаком «+» — от B.
Git любезно выбирает «A» и «B» таким образом, что (в большинстве случаев) вы можете рассматривать A (или «-») как «старый» контент, а B (или «+») как «новый» контент.
Наш пример помогает нам понять это:
Изменение № 1 содержит две строки с добавлением «+». Поскольку для этих строк не существует аналога в A (нет строк с «-»), это означает, что строки были добавлены.
Изменение № 2 является совершенно противоположным: у нас есть две строки, помеченные знаком «-» в A. Поскольку B не имеет эквивалента (без «+»), это означает, что они были удалены.
Наконец, некоторые строки были фактически изменены: в Изменении №3 две строки «-» были изменены, чтобы выглядеть как две строки «+» ниже.
Теперь вы знаете, как читать и понимать вывод diff. Теперь давайте посмотрим, как сгенерировать часть этого вывода в Git.
Проверка локальных изменений
Прежде чем вносить изменения, вы захотите увидеть, что именно вы сделали. Команда «git diff» покажет вам все ваши локальные изменения, которые еще не были добавлены в «Стадионную область» Git: $ git diff
Если вместо этого вы хотите видеть только те изменения, которые вы уже сделали, вы можете сделать это, добавив параметр «–staged» в команду.
Проверка совершенных изменений
Изменения, которые уже были внесены в репозиторий, можно проверить с помощью команды «git log». По умолчанию он только выдает обзор метаданных коммита (например, автора, сообщения и даты). Если вы добавите флаг «-p», вы также можете запросить подробную информацию о точных изменениях:
Сравнение ветвей и версий
Различия также полезны, когда вы хотите понять, чем одна ветка (или даже конкретный коммит) отличается от другой. Например, вам может быть интересно увидеть все изменения из ветки «контактная форма», которых у вас еще нет в «мастер». Для этого используйте команду «git diff» следующим образом: $ git diff master..contact-form
Но вы не ограничены сравнением веток. Вы даже можете сравнить два произвольных коммита друг с другом: $ git diff 0023cdd..fcd6199
Инструменты для более четкой визуализации
При рассмотрении более крупных и сложных модификаций вам может понадобиться вся помощь, которую вы можете получить. Специальное приложение для анализа различий обеспечит улучшенную визуализацию и тем самым облегчит понимание изменений.
Чтобы помочь вам выбрать один из множества доступных инструментов в этой области, взгляните на этот обзор рекомендуемых приложений .
Вывод
Я надеюсь, что эта статья показала вам, что различия (хотя они могут предложить иное при первом рассмотрении) не просто неясное искусство ASCII. Как только вы научитесь их читать, они позволят вам понять, как развивался ваш проект. Это делает их важным инструментом для каждого члена команды разработчиков.