Что такое контроль версий: более эффективно управляйте своей кодовой базой

12 января 2024 г.

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

Основы

Когда вы программируете, у вас будет много взаимосвязанных файлов, состояние которых должно быть точным, чтобы все работало. В случае с самыми простыми приложениями вы можете управлять файлами самостоятельно. Однако по мере роста сложности приложения сложность отслеживания изменений возрастает еще быстрее.

Контроль версий — это инструмент для управления состоянием кодовой базы. Это дополнительный уровень контроля над файлами, хранящимися на диске. Итак, наряду с вашими файлами у вас есть репозиторий кода, в котором хранится дополнительная информация:

• предыдущие версии кода
• наборы изменений, которые можно применить или отменить вместе, и
• описания и метаданные для наборов изменений.

С помощью контроля версий вы можете хранить снимки кода. Вы можете думать об этом как о своего рода «сохранении» для развития — месте, куда вы всегда можете вернуться, если что-то испортите. Как и в играх, регулярное сохранение прогресса помогает избежать необходимости выполнять одно и то же задание дважды.

Гит

В настоящее время Git является фактическим стандартом контроля версий в отрасли. Вы можете с уверенностью предположить, что это все, что вам нужно как новичку: хорошо разбираясь в Git, вы сможете выбрать любой инструмент, который ваш сотрудник может потребовать от вас.

Git — это распределенная система: в типичном случае каждый имеет полную копию репозитория на своих машинах. Копии репозитория можно легко синхронизировать. Обычно у вас есть центральный удаленный репозиторий, который часто называют «источником», и каждый разработчик синхронизируется с этим репозиторием.

Централизованные репозитории часто размещаются у внешних поставщиков, например:

• GitHub,
• GitLab,
• CodeSummit от AWS,
• или другие.

Влияние на производительность

Давайте посмотрим, как использование контроля версий может повысить вашу производительность.

Отменить локальные изменения

Первое преимущество заключается в возможности быстрого возврата любых изменений, внесенных вами локально. Иногда, чтобы внести одно изменение, вам нужно изменить код во многих местах. Без контроля версий вернуться к тому, что уже работало, может быть сложно: представьте, что вам нужно отменить изменения в пяти разных файлах в вашем редакторе кода. Вы можете быть сколь угодно осторожны, но иногда вам будет сложно вернуться в прошлое, если только вы не создадите снимки рабочего приложения с контролем версий.

Интегрируйте изменения из многих источников.

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

Git отслеживает все изменения отдельно и имеет мощную функцию трехстороннего слияния: сравнение двух версий файла, которые объединяются, и исходного состояния до того, как они разошлись. Благодаря этой возможности Git часто может интегрировать изменения без вмешательства разработчика — и я никогда не видел, чтобы такие автоматические слияния приводили к недействительному коду.

Восстановить предыдущие версии

Иногда вам хочется вернуть свой код туда, где он был раньше — Git поможет вам. У вас есть много вариантов добиться этого возврата:

• git checkout <version> в какой-то предыдущей версии — чтобы вы могли увидеть, как код работал в данный момент.
• git reset --hard <version> — переместите ветку на определенную версию, удалив изменения, внесенные с этого момента.
• git checkout <version> -- <file> — восстановить данный файл до его состояния в какой-либо другой версии.

Когда вы работаете над базой кода, эти функции действительно пригодятся.

История

Чем дольше живет проект и чем больше изменений происходит на протяжении его существования, тем большую ценность можно найти в его истории. Хорошо поддерживаемая история с хорошо описанными атомарными коммитами может дать представление о том, почему в базе кода все обстоит именно так, как сейчас. Эта информация может помочь будущим разработчикам принимать обоснованные решения об изменениях кода. В другой статье я писал о создании полезной истории Git. .

Откат определенного обновления

Git позволяет вам отменить очень специфические наборы изменений с помощью git revert <version>. Эта команда пытается привести все затронутые файлы в состояние до изменения. Часто требуется разрешение конфликтов вручную и добавляется новая фиксация для отмены изменений. Это еще одна причина, по которой ваши коммиты должны быть небольшими и содержать тесно связанные изменения.

Что попадает в репозиторий?

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

Исходный код

Исходный код нашего приложения — наиболее очевидный пример. В случае веб-сайта мы поместим все связанные файлы HTML, JS, CSS и т. д. в репозиторий.

Код, который вы поддерживаете, является идеальным вариантом для контроля версий. Возьмем следующие случаи:

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

Описание зависимостей

Для кода, который вы используете, но не поддерживаете, вы обычно храните только информацию о зависимостях. В случае приложений JavaScript это файлы package.json и package-lock.json. Зависимости можно загрузить с помощью менеджера пакетов в тех местах, где мы хотим запустить код. Затем менеджер пакетов должен убедиться, что установлены правильные версии.

Двоичные файлы

В вашей кодовой базе могут появиться некоторые двоичные файлы. Вы можете ожидать медиафайлы, которые используются в интерфейсе приложения: логотипы или другие изображения, файлы со звуковыми эффектами и т. д.

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

Что остается за пределами репозитория

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

База данных

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

Жизненные циклы изменений данных и кода сильно различаются. Код вы создаете локально, тестируете на промежуточном сервере и, наконец, развертываете в рабочей среде. Что касается данных, вам нужна отдельная база данных для каждой среды, при этом некоторые изменения время от времени перемещаются по всем из них в том или ином направлении.

Базы данных, скорее всего, сжимают данные и сохраняют их в виде двоичных файлов, а, как мы обсуждали ранее, в Git это проблематично. Единственное, что вам нужно для локального запуска приложения, — это демонстрационная база данных. Вы можете получить это с помощью специального контейнера, заполненного данными примера, или с помощью сценария инициализации базы данных, который вы храните в базе кода. Оба подхода более подходят, чем хранение базы данных в репозитории.

Встроенный код

Нет причин хранить код сборки в репозитории. Это двоичный файл, он займет много места, и его ценность ограничена. Вы всегда можете пересобрать его прямо из кода. Для хранения результатов сборки вам понадобится какое-то другое решение в качестве репозитория артефактов: реестр пакетов — это тот, который вы можете получить из NPM для узловых модулей, и репозиторий контейнеров для вещей, которые развертываются с помощью образов контейнеров.

Зависимости

Добавление зависимостей в репозиторий (фиксация node_modules) имеет несколько больших недостатков:

• Ваш репозиторий значительно увеличивается, а код вы в основном оставляете без изменений.
• Ваши коммиты станут менее понятными — за 100 строк собственных изменений вы можете получить десятки тысяч строк в некоторых сторонних библиотеках, и
• Некоторые сторонние зависимости устанавливаются по-разному в зависимости от операционной системы. Станет сложнее обмениваться кодом между операционными системами со значительными различиями между ними, например между Windows и macOS.

Загрузки пользователей

В случае веб-сайтов загрузка пользователя может оказаться внутри дерева каталогов вашего приложения. Это то, что я часто видел, когда работал над веб-сайтами PHP. Тем не менее, эти файлы не принадлежат вашему репозиторию кода — вам нужно найти другой способ управления ими, а кроме того, убедитесь, что вы не удалите их при развертывании новой версии приложения.

Репозиторий в действии

Давайте посмотрим несколько примеров репозитория Git. Вы можете исследовать репозитории с помощью локального клиента Git или на хостинговых платформах, таких как GitHub. Давайте взглянем на репозиторий lodash на GitHub.

Кодовая база

Git предоставляет вам представление любой версии. Текущее состояние репозитория:

Или версия 1.0.0 12 лет назад:

Дерево

Один из моих любимых представлений — все изменения отображаются в дереве коммитов. Из основной ветки:

Зафиксировать разницу

Вы можете увидеть изменения, внесенные в конкретный коммит, как разницу между всеми файлами в проект:

Атрибуция

Если вы хотите узнать автора последнего изменения в строке, вы можете использовать команду с аккуратным названием git Assessment или просмотреть файл файл в режиме обвинения на GitHub:

Сводка

Контроль версий — важнейший инструмент в арсенале любого разработчика. Неиспользование его гарантирует, что в конечном итоге вы потеряете некоторое время. Обучение использованию Git требует усилий, но это вложение, которое сторицей окупится, когда вы программируете — даже во время учебы или работы над личными проектами.

---

Также опубликовано здесь.

---

Оригинал