Локальный Rebase в 1С:EDT. Просто о сложном.

Локальный Rebase в 1С: EDT. Просто о сложном.

Локальный Rebase в 1С:EDT - это мощная и достаточно продвинутая операция по актуализации вашей локальной ветки (синхронизация с последними изменениями) перед тем, как выполнять слияние с главной веткой.

Давайте разберём подробно, что это такое, зачем нужно и как работает.

Для начала примем договорённость: в удалённом репозитории Git существует главная ветка с именем dev. Обычно главной ветке дают такие имена, как main, develop или просто dev. В нашем примере имя главной ветки - dev.

Зачем это нужно в 1С:EDT?

Прежде всего - для вашей локальной ветки. Например, вы создали от главной ветки dev свою локальную ветку и переименовали её в feature/my-branch.

Нажимаем «Готово».

Локально появится новая ветка с заданным именем.

Как это выглядит схематически в терминах веток репозитория Git:

На рисунке новая ветка указывает на тот же самый коммит, что и ветка dev.

В дальнейшем, после первого коммита, картина будет выглядеть примерно так:

На рисунке видно, что в новой ветке были зафиксированы изменения. Новая ветка и ветка dev указывают на разные коммиты.

Важная информация

Обратим внимание: при создании новой ветки не происходит фиксации изменений (нового коммита).
Следовательно, на этом шаге уникальные идентификаторы последних коммитов у ветки dev и у новой ветки feature/my-branch совпадают.

Если два коммита имеют одинаковый уникальный идентификатор (хеш-сумму), это один и тот же коммит.

Что происходит технически:

1. Git создает новый указатель feature/my-branch

2. Этот указатель устанавливается на тот же коммит , на который указывает dev

3. Обе ветки ссылаются на коммит с идентификатором 38ccc60

4. Ветки отличаются только указателями, но не содержанием

Для информации: Справа от ветки видим служебную информацию - уникальный идентификатор последнего коммита в ветке dev, от которой мы извлекли ветку. В Git каждый коммит характеризуется уникальным идентификатором. 

"Уникальные идентификаторы" здесь - это хеш-суммы коммитов, которые Git гарантирует, как уникальные для каждого коммита

Работа в ветке

После создания новой локальной ветки мы можем переключиться в перспективу 1С и выполнять доработки.

Например: вы работали в своей ветке feature/my-branch несколько дней. За это время в основную ветку dev коллеги уже влили (merge) свои изменения. Чтобы убедиться, что ваш функционал работает с самой последней версией кода, вы перебазируете свою ветку на свежую dev. Это помогает выявить конфликты до создания Merge Request.

Если говорить просто, локальный rebase - это операция переноса ваших изменений поверх новых изменений, которые появились в главной ветке dev с момента начала вашей работы.

Подготовка к rebase

За время работы в удалённом репозитории могли произойти изменения — коллеги добавили свои коммиты в ветку dev.

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

Для начала необходимо актуализировать служебную ветку.

Для информации: В 1С:EDT в перспективе Git есть структура папок. В ней есть специальная служебная папка «Удаленное отслеживание» (Remote Tracking). Внутри нее находятся ветки, относящиеся к специальному типу веток, которые создаются Git для отслеживания состояния соответствующих веток на удаленном репозитории. 

Ветки удаленного отслеживания - это локальные копии веток из удаленного репозитория (например, с GitLab, GitHub). Они имеют специальные имена в формате: remotes/origin/имя_ветки

Например:

Ветки remotes/origin/* являются read-only. Вы не можете в них напрямую коммитить. Они обновляются только специальными командами Git через консоль либо интерактивно 

Давайте обновим служебную ветку remotes/origin/dev которая отслеживает изменения главной ветки в удаленном репозитории. Сделаем это интерактивно через команды EDT:

В последнем диалоговом окне отобразится список всех коммитов, которые были «слиты» в ветку dev. 

Обновление служебной ветки remotes/origin/dev завершено. Теперь задача - перенести свои локальные доработки "поверх" новых изменений главной ветки dev. 

Процесс перебазирования

Для перебазирования локальной ветки поверх изменений главной ветки dev в EDT существует команда «Перебазировать»

Позиционируемся на ветке из «Удаленного отслеживания», поверх которой мы будем вносить наши изменения: 

Запускаем процесс перебазирования (rebase), обращаем внимание на правый нижний угол в перспективе Git: 

Для запуска старта операции перебазирования нажимаем в соответствующем окне команду «Старт»:

Что происходит технически?

Поскольку нам нужно наши изменения перенести поверх актуализированной ветки dev из удаленного отслеживания, то с нашей локальной ветки коммиты временно снимаются, она как бы замещается на состояние выбранной ранее ветки dev. И теперь наша задача поверх нее «накатить» наши коммиты. Этот процесс пошаговый и количество шагов есть количество наших сделанных коммитов.

Разрешение конфликтов

Напомним, что в 1С: EDT мы работаем с конфигурацией как с распределенной структурой файлов и папок. Например, мы добавили новый справочник «НовыйСправочник». Что поменялось в локальном репозитории? 

На скиншоте мы видим локальный репозиторий Git.

«Сердцем» распределенной структуры файлов конфигурации является файл Configuration.mdo, который отвечает за описание структуры конфигурации базы 1С.

Допустим, мы отнесли новый справочник к подсистеме «Служебная». Таким образом мы изменили состав соответствующей подсистемы. Соответственно откроется окно для разрешения конфликтов:

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

Конфликты возникают в том случае, если в процессе вашей работы в главную ветку были добавлены новые объекты.

Нажимаем «Продолжить» для разрешения конфликтов: 

Разрешаем конфликты в «проблемных» файлах. Копируем текущее изменение справа/налево - ВНИМАТЕЛЬНО (могут дублироваться объекты и др.)

Сохранить файл после отработки всех конфликтов (Ctrl+S) и перейти к следующему файлу, относительно которого обнаружен конфликт.

Переходим на вкладку (окно) «Индексирование Git» - Неиндексированные изменения - Добавить выбранные файлы в индекс

Важно! Результат фиксировать НЕ НУЖНО. Нажимаем продолжить

EDT продолжает rebase, переходя на следующий шаг (отработка следующего коммита). Можно снова перейти на вкладку «Interactive rebase» чтобы проследить работу EDT. 

В случае, если конфликтов при отработке следующего коммита не будет обнаружено, система автоматически будет переходить к следующему шагу, «просигналит» аналогичным образом только в случае очередного конфликта, требующего «ручного» вмешательства со стороны разработчика.

Завершение и проверка 

Итого после решения всех конфликтов (для каждого коммита в ветку) проверяем историю локальной ветки: является наследником dev, есть n коммитов текущей ветки от dev
Проверяем историю ветки:

Отправляем ветку в удаленный репозиторий

Результат перебазирования (rebase) схематически можно представить так: 

Что происходит технически:

1. Берётся ваша текущая локальная ветка (например, feature/my-branch)

2. Временно снимаются ваши коммиты с этой ветки

3. Ветка переключается на актуальный конец целевой ветки (в нашем случае, origin/dev)

4. Ваши коммиты применяются заново поверх новых изменений

5. Ветка feature/my-branch обновляется - теперь она указывает на новую цепочку коммитов

Обратите внимание:

Ветка feature/my-branch осталась с тем же именем

Но коммиты, условно обозначим как E, F, G, были пересозданы как E', F', G' (с новыми хешами, т.е. уникальными идентификаторами)

История была переписана - это ключевая характеристика rebase

Заключение

Локальный rebase - это мощный инструмент, который помогает поддерживать вашу ветку в актуальном состоянии и обеспечивать беспроблемную интеграцию изменений в главную ветку (merge). Основные преимущества этого подхода:

Чистая история коммитов - линейная история без лишних merge-коммитов
Раннее обнаружение конфликтов - проблемы решаются до создания Merge Request
Уверенность в совместимости - ваш код тестируется с самой свежей версией главной ветки 

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

Автор статьи:

Ангелин Александр 

Ведущий разработчик 1С 

ООО КРОН