Локальный 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 совпадают.
Если два коммита имеют одинаковый уникальный идентификатор (хеш-сумму), это один и тот же коммит.
Что происходит технически:
Git создает новый указатель feature/my-branch
Этот указатель устанавливается на тот же коммит , на который указывает dev
Обе ветки ссылаются на коммит с идентификатором 38ccc60
Ветки отличаются только указателями, но не содержанием
Для информации: Справа от ветки видим служебную информацию - уникальный идентификатор последнего коммита в ветке 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/dev - отслеживает ветку dev с удаленного сервера remotes/origin/feature/new-report - отслеживает ветку feature/new-report
Ветки remotes/origin/* являются read-only. Вы не можете в них напрямую коммитить. Они обновляются только специальными командами Git через консоль либо интерактивно
Давайте обновим служебную ветку remotes/origin/dev которая отслеживает изменения главной ветки в удаленном репозитории. Сделаем это интерактивно через команды EDT:
В последнем диалоговом окне отобразится список всех коммитов, которые были «слиты» в ветку dev.
Обновление служебной ветки remotes/origin/dev завершено. Теперь задача - перенести свои локальные доработки "поверх" новых изменений главной ветки dev.
Процесс перебазирования
Для перебазирования локальной ветки поверх изменений главной ветки dev в EDT существует команда «Перебазировать»
Позиционируемся на ветке из «Удаленного отслеживания», поверх которой мы будем вносить наши изменения:
Устанавливаем check-box «Перебазировать интерактивно» что даст в дальнейшем возможность решить конфликты в контролируемой среде
Запускаем процесс перебазирования (rebase), обращаем внимание на правый нижний угол в перспективе Git:
Для запуска старта операции перебазирования нажимаем в соответствующем окне команду «Старт»:
Что происходит технически?
Поскольку нам нужно наши изменения перенести поверх актуализированной ветки dev из удаленного отслеживания, то с нашей локальной ветки коммиты временно снимаются, она как бы замещается на состояние выбранной ранее ветки dev. И теперь наша задача поверх нее «накатить» наши коммиты. Этот процесс пошаговый и количество шагов есть количество наших сделанных коммитов.
Разрешение конфликтов
Напомним, что в 1С: EDT мы работаем с конфигурацией как с распределенной структурой файлов и папок. Например, мы добавили новый справочник «НовыйСправочник». Что поменялось в локальном репозитории?
На скиншоте мы видим локальный репозиторий Git.
«Сердцем» распределенной структуры файлов конфигурации является файл Configuration.mdo, который отвечает за описание структуры конфигурации базы 1С.
Допустим, мы отнесли новый справочник к подсистеме «Служебная». Таким образом мы изменили состав соответствующей подсистемы. Соответственно откроется окно для разрешения конфликтов:
Таким образом в результате доработок изменилось содержимое общих файлов отвечающее за описание содержимого объектов конфигурации и содержимое подсистемы.
Конфликты возникают в том случае, если в процессе вашей работы в главную ветку были добавлены новые объекты.
Нажимаем «Продолжить» для разрешения конфликтов:
Разрешаем конфликты в «проблемных» файлах. Копируем текущее изменение справа/налево - ВНИМАТЕЛЬНО (могут дублироваться объекты и др.)
Сохранить файл после отработки всех конфликтов (Ctrl+S) и перейти к следующему файлу, относительно которого обнаружен конфликт.
Переходим на вкладку (окно) «Индексирование Git» - Неиндексированные изменения - Добавить выбранные файлы в индекс
Важно! Результат фиксировать НЕ НУЖНО. Нажимаем продолжить
EDT продолжает rebase, переходя на следующий шаг (отработка следующего коммита). Можно снова перейти на вкладку «Interactive rebase» чтобы проследить работу EDT.
В случае, если конфликтов при отработке следующего коммита не будет обнаружено, система автоматически будет переходить к следующему шагу, «просигналит» аналогичным образом только в случае очередного конфликта, требующего «ручного» вмешательства со стороны разработчика.
Завершение и проверка
Итого после решения всех конфликтов (для каждого коммита в ветку) проверяем историю локальной ветки: является наследником dev, есть n коммитов текущей ветки от devПроверяем историю ветки:
Отправляем ветку в удаленный репозиторий
Результат перебазирования (rebase) схематически можно представить так:
Что происходит технически:
Берётся ваша текущая локальная ветка (например, feature/my-branch)
Временно снимаются ваши коммиты с этой ветки
Ветка переключается на актуальный конец целевой ветки (в нашем случае, origin/dev)
Ваши коммиты применяются заново поверх новых изменений
Ветка feature/my-branch обновляется - теперь она указывает на новую цепочку коммитов
Обратите внимание:
Ветка feature/my-branch осталась с тем же именем
Но коммиты, условно обозначим как E, F, G, были пересозданы как E', F', G' (с новыми хешами, т.е. уникальными идентификаторами)
История была переписана - это ключевая характеристика rebase
Заключение
Локальный rebase - это мощный инструмент, который помогает поддерживать вашу ветку в актуальном состоянии и обеспечивать беспроблемную интеграцию изменений в главную ветку (merge). Основные преимущества этого подхода:
Чистая история коммитов - линейная история без лишних merge-коммитовРаннее обнаружение конфликтов - проблемы решаются до создания Merge RequestУверенность в совместимости - ваш код тестируется с самой свежей версией главной ветки
Важные напоминания:Всегда обновляйте ветки удаленного отслеживания перед rebaseВнимательно разрешайте конфликты -это ключ к успешному rebaseПосле rebase обязательно тестируйте свой функционалОсвоив локальный rebase, вы значительно упростите процесс код-ревью и слияния изменений в команде.