Как управлять версиями вашего SQL
Руководство для начинающих – начало работы с git
Зачем нужен контроль версий SQL? Потому что SQL - это код.
Мой интерес к контролю версий начался тогда, когда моей команде поручили большой проект по конверсии. Мы изменили сотни SQL-запросов с одного диалекта SQL на другой.
Теоретически я знал, что контроль версий может:
- Помочь нам сравнить запросы, чтобы найти различия
- Сравнить предыдущую версию с новой версией запроса.
- Разрешить мне отменить изменение, внесенное в мой код, которое не имело ожидаемого эффекта.
- Разрешить нашей команде сотрудничать, когда кому-то нужна помощь с запросом
Но на практике я понятия не имел, как все это будет работать.
Изучать git сложно. Даже просто понять, что такое git, может быть сложно, если вы никогда раньше не пользовались системой контроля версий.
Существует множество ресурсов для понимания git, и все они имеют больше смысла, когда вы уже понимаете git. Я думаю, что лучший способ учиться — это брать и делать.
Этот учебник показывает вам, как работает git, не объясняя все его загадки. Я покажу вам, как настроить управление версиями SQL с помощью GitHub и DBeaver.
Минимально жизнеспособные концепции Git
У вас на компьютере может быть каталог с кучей файлов, который выглядит так:
SuperImportantQuery.sql SuperImportantQuery-Weekly.sql SuperImportantQuery-April-Wk1.sql SuperImportantQuery-April-New.sql SuperImportantQuery-April-WK3.sql SIQ2.sql SIQ3.sql
Контроль версий — это альтернатива сохранению нескольких копий файла для сохранения истории изменений.
С контролем версий приведенный выше список может выглядеть так:
SuperImportantQuery.sql SuperImportantQuery-Weekly.sql
С контролем версий у вас по-прежнему будет вся история, которую предоставляют несколько копий (или больше), без сохранения всех копий! Это волшебно! ✨
Контроль версий отслеживает изменения в файлах кода, например SQL-запрос. Git — это тип распределенного контроля версий. Набор изменений регистрируется программным обеспечением контроля версий, когда вы делаете коммит. Коммиты сопровождаются сообщениями, объясняющими причины изменения.
Git отслеживает изменения между коммит версиями на построчном уровне. Вы можете сравнить любую версию с предыдущей или текущей итерацией. Поскольку git сохраняет различия между версиями, он может использовать их для восстановления любой предыдущей версии запроса, который вы фиксировали. Вы можете сбросить свое рабочее пространство до предыдущей версии запроса, если решите, что вам нужно отменить внесенное вами изменение.
Сообщения коммита сопровождают каждый коммит и содержат обоснование изменения. Сообщения коммита, если они написаны правильно, объясняют, почему было сделано определенное изменение. Вам не нужно объяснять, что изменилось, потому что git отследит это за вас.
Несколько человек могут сотрудничать, отправляя свои изменения в виде коммитов в репозиторий. Репозитории — это место, где git хранит ваш код и ваши изменения. Git является распределенным, а это означает, что у каждого участника есть полная копия репозитория, а также есть дополнительная копия в источнике git или на удаленном сервере.
В этом руководстве будут продемонстрированы все эти минимально жизнеспособные концепции git.
Обзор
Мы настроим DBeaver для связи с репозиторием на GitHub, который мы создадим. В этом репозитории мы создадим запрос, используя образец базы данных DBeaver, и зафиксируем оригинал плюс два изменения.
Шаг 1: Установите DBeaver
Я использую бесплатную версию сообщества DBeaver. Разрешите DBeaver установить бесплатную пробную базу данных — мы будем использовать ее позже.
На этом шаге мы получаем инструмент запросов SQL и базу данных для работы.
Шаг 2. Установите расширение Git в DBeaver.
В DBeaver перейдите в раздел «Справка» -> «Установить новое программное обеспечение».
В раскрывающемся списке «Работа с» выберите: https://dbeaver.io/update/git/latest/
Установите флажок Поддержка DBeaver Git и завершите установку, следуя инструкциям.
(Если вы любите темный режим, вы можете установить тему Darkest Dark из того же меню. Мой DBeaver темный на гифках и скриншотах ниже)
На этом этапе DBeaver настраивается для взаимодействия с репозиториями git.
Шаг 3. Создайте пустой репозиторий на GitHub.
Репозиторий — это папка с коллекцией файлов, синхронизированных с удаленным (источником). Изменения в файлах в репозитории отслеживаются, когда вы их коммитите. Я назвал свой git_in_DBeaver.
На этом этапе мы настраиваем удаленный репозиторий. Мы будем использовать расширение git, которое мы только что установили, для связи с ним. Командная строка не требуется.
Шаг 4: Создайте проект из своего репозитория в DBeaver
Теперь мы расскажем DBeaver, как найти наш репозиторий.
DBeaver имеет файловую структуру по умолчанию для каждого проекта, которую он использует для организации соединений, сценариев и других артефактов. Настройка вашего проекта из DBeaver с использованием только что созданного вами пустого репозитория гарантирует, что он сможет разместить все свои файлы там, где захочет.
Во-первых, мне понадобится URL моего репозитория из git. Скопируйте адрес, указанный при нажатии на кнопку клонирования или загрузки.
Следуйте инструкциям на картинке ниже, чтобы добавить репозиторий в качестве проекта DBeaver. Сохраняйте настройки по умолчанию. Если ваш URI репо скопирован в буфер обмена, он будет автоматически заполнен.
Теперь, когда мы завершили этот шаг, на панели проектов появится проект DBeaver с тем же именем, что и репозиторий, с которым он синхронизируется.
Шаг 5: Откройте Git Staging
Эта панель рабочего пространства DBeaver позволит нам видеть состояние наших файлов, писать сообщения коммита и отправлять изменения в наш удаленный репозиторий. Он не открывается автоматически, поэтому вам нужно выполнить следующие шаги, чтобы показать его.
Все до этого момента было настроено – подготовка к написанию и контролю версий SQL. Сейчас мы переключим передачу и…
Шаг 6: Наконец, напишем немного SQL
В этой части руководства вы можете работать с собственным репозиторием или читать дальше. Во-первых, я собираюсь скопировать пример подключения к базе данных из общего проекта в новый, который я создал.
Вы работаете аналитиком в вымышленной компании Sample Tunes Inc. Ваш босс просит вас выяснить, каковы продажи компании по категиориям. Для этого мы будем использовать образец базы данных в DBeaver, в которой есть таблицы InvoiceLine, Track и Genre.
Во-первых, давайте напишем SQL-код, чтобы подсчитать доллары с продаж для каждой строки счета-фактуры, используя образец базы данных.
SELECT Quantity*UnitPrice AS SalesDollars ,TrackId FROM InvoiceLine GROUP BY InvoiceId
Я создал этот файл в своем проекте DBeaver, сохранил его и назвал SalesbyGenre.
Шаг 7: Простой рабочий процесс Git
Мы будем следовать этому простому рабочему процессу git, когда будем вносить изменения в наш запрос SalesbyGenre.sql.
Давайте посмотрим на рабочий процесс и где мы находимся:
- Внесите изменения в файл запроса
- Сохраните изменения
- Проведите изменения - мы здесь
- Напишите описательное сообщение коммита
- Зафиксируйте и отправьте изменения
На данный момент мы сохранили изменения, которые не зафиксировали.
В DBeaver мы увидим эти изменения в промежуточном окне под неустановленными изменениями. Git сообщает нам, что у нас есть изменения в наших файлах, о которых он не знает.
Изменения стейджинга
Если вы посмотрите на мое промежуточное окно, то увидите мой скрипт, но вы также увидите нераспознанный файл .project. Это файл DBeaver, который мы бы не хотели контролировать версиями, поэтому я пока его проигнорирую и внесу свои изменения. Staging сообщает git, какие файлы вы хотели бы включить в свой коммит.
Написание сообщения коммита, коммит и отправка
Первый коммит добавит мой запрос в репозиторий — сообщение, которое я пишу для его сопровождения, будет иметь тему и тело.
Субъект завершает предложение «Если применить, этот коммит… добавит сценарий для продаж по жанрам». Когда вы извлекаете изменения, внесенные кем-то другим в удаленное хранилище, в этих строках темы описываются изменения, которые будут применены к вашим локальным копиям файла (файлов).
Обычно причина изменения объясняется в теле сообщения, которое отделяется от темы пустой строкой.
Для отправки на GitHub я использовал следующий формат в полях автора и коммиттера DBeaver.
erika-e <erika.swartz@gmail.com>
Когда я отправил, DBeaver предложил мне ввести имя пользователя и пароль GitHub. Первое сообщение коммита и изменения теперь появятся в репозитории на GitHub.
Замечу, что вам не нужно отправлять каждый коммит. Рабочие процессы Git выходят за рамки этого руководства.
Вернемся к нашему простому рабочему процессу и посмотрим, где мы:
- Внесите изменения в файл запроса
- Сохраните изменения
- Внесите изменения
- Напишите описательное сообщение коммита
- Зафиксируйте и отправьте изменения
Для каждого изменения, которое мы вносим, мы повторяем один и тот же рабочий процесс.
Что в коммите
Вот анимация второго коммита, который я сделал для своего запроса, добавляя соединения к запросу. Здесь показано, как использовать промежуточное окно для написания сообщения коммита.
Давайте подробнее рассмотрим этот второй коммит с помощью снимка экрана с GitHub. Здесь мы рассмотрим некоторые «волшебные» возможности git.
Git предоставляет сводку коммита: 1 измененный файл с 7 добавлениями и 3 удалениями. В представлении различий эти изменения выделяются зеленым и красным цветом для добавлений и удалений соответственно.
Вот где git показывает свою мощь. Мне никогда не приходится писать сообщение или комментарий, документируя изменения, потому что git отслеживает это за меня. С помощью различий я вижу, что меняется от версии к версии файла — мне никогда не приходится сохранять копию. Сообщения комминта не документируют (и не должны) документировать изменения, поэтому вы можете сосредоточиться на причинах изменений.
Сообщения коммита могут быть важной формой документации кода. В этом случае тело моих сообщений полезно лишь немного. Это не говорит вам, почему я присоединился к жанру и треку, только то, что желаемый результат — это продажи по жанрам.
В более полезном сообщении можно было бы сказать: «InvoiceLine имеет TrackId в каждой записи строки счета, присоединяясь к Track для присоединения к GenreId и Genre для присоединения к названиям жанров».
Подведение итогов
Вы можете увидеть окончательную версию моего запроса на GitHub ниже.
SELECT G.Name AS Genre ,SUM(IL.Quantity*IL.UnitPrice) AS SalesDollars FROM InvoiceLine IL LEFT JOIN Track T on T.TrackId = IL.TrackId LEFT JOIN Genre G on T.GenreId = G.GenreId GROUP BY G.Name ORDER BY SUM(IL.Quantity*IL.UnitPrice) DESC
Когда я создавал свой запрос, я фиксировал свои изменения. Представление истории в DBeaver (или на GitHub) показывает мне три версии моего скрипта. Каждая показывает идентификатор коммита и первую строку моего сообщения коммита.
Каждое сделанное мной изменение я отправлял в источник, который является копией моего репозитория на GitHub. Все изменения были внесены в основную ветку.
По мере того, как вы углубляете свое понимание git, вы узнаете более сложные концепции, которые выходят за рамки этого руководства. Такие концепции, как рабочие процессы git для совместной работы, ветки для новых функций, перебазирование и управление конфликтами слияния, делают git мощным и эффективным инструментом управления кодом.