Работа с git

Очень понравилась картинка - ярко характеризуют работу с гитом, когда всегда что-то идет не так.

В принципе даже сейчас в EDT порой git себя ведет странно, например, cherry-pick я так и не научился в нем делать. В консоли или GitLab это удается сделать сильно проще и быстрее.

#git

Методика постепенного перехода на EDT

Методика постепенного перехода на разработку в 1С:EDT - https://its.1c.ru/db/edtdoc#content:10219:hdoc
Суть методики: хранилище конфигурации выгружается в git с помощью Гитконвертера (или других инструментов) и разработчик может вести проект в EDT или Конфигураторе.

Этой методикой мы пользуемся с 2017 года - это уже 7 лет. Вот такой о-о-очень постепенный переход получается.

Причем первые года 3-4 мы даже не разрабатывали в EDT. Выгрузку в git использовали только для работы сторонних инструментов типа SonarQube и Crucible. Чуть позже начали разрабатывать свои проверки конфигурации, так как с файлами работать гораздо проще, чем с хранилищем. Об этом расскажу позже.

Затем потихоньку начали переключаться на работу в EDT, но шло это не просто. До сих пор остаются сложности даже у тех, кто полностью работает в этой среде. Причем мы не были пионерами в этой области, а сейчас держимся крепкими середнячками в сравнении с другими отделами фирмы «1С».

Лишь часть команд в нашем отделе работают в EDT, а остальные либо не хотят, либо сомневаются. Расстановка сил подчиняется Правилу 3-4-3, где из 10 человек трое За, трое Против, а четверо Не определились и ждут в какую сторону качнутся весы.
Но даже те, кто не спешит переходить с удовольствием используют возможности гита: сборку патчей, git blame, git merge, SonarQube и Crucible.

Наш семилетний путь по переходу на EDT не завершается. Мы планируем поддерживать и хранилище, и git. За это приходится платить администрированием Гитконвертера, но это уже понятная и привычная цена.

#git #EDT

git merge

Помимо смешных пятничных картинок хотел поделиться болью при использовании git merge в промышленной разработке.

У нас технические проекты тоже выгружаются в git, хотя разработку в них ведут в Конфигураторе. При этом релизы в основной ветке выходят примерно раз в две недели, но разработка задачи часто превышает этот период.
Поэтому проекты переодически актуализируются на новую версию конфигурации.

И вот здесь появляется проблема при использовании ГитКонвертера.
При сравнении и объединении с новой конфигурации поставщика должен происходить git merge. Но ГитКонвертер об этом ничего не знает и при выгрузке делает очередной коммит, в котором появятся все изменения из новой конфигурации поставщика. На картинке - это первая пунктирная линия. То есть должен быть git merge, но его нет.

Когда такой проект нужно отправить на код-ревью, с помощью Pull/Merge request, то разница между основной и веткой проекта получается большой. Это происходит из-за того, что родительским коммитом будет момент открытия, а не актуализации. То есть в изменениях будут все коммиты сделанные в проекте, в том числе и наш коммит с актуализацией проекта. И именно он привносит с собой много лишних изменений. На картинке - это вторая (красная) пунктирная линия.

В понедельник расскажу как мы боремся с этой проблемой.

#git #EDT

Проблема git merge

Итак на картинке отображена наша исходная ситуация и проблема.

Коротко суть:
1. Есть основное хранилище, которое выгружается в git
2. Есть проектное хранилище, которое выгружается в git
3. Ветка для проектного хранилища создана с родительским коммитом от мастера
4. Актуализация с основным хранилищем происходит в Конфигураторе и в гите отображается как обычный коммит

Проблема:
При попытке сделать мердж или пулл реквест показываются лишние изменения

Причина проблемы:
Актуализация не имеет связи с основной веткой и поэтому для гита - это всего лишь очередной коммит.

Решение:
Пересоздать ветку от мастера после актуализации и настроить новую выгрузку в Гитконвертере.

Порядок действий:
Все решение выполняются на стороне Гитконвертера, в хранилище разработчика ничего не делаем.
1. В локальном репозитории переключитесь на ветку main на коммит, с которым происходила актуализация. В нашем случае это 3.0.154.
2. Создайте ветку от этого коммита. Мы называем такую ветку с постфиксом _2.
3. В Гитконвертере укажите эту ветку как целевую
4. В Гитконвертере укажите версию с которой выполняется конвертация та, которая соответствует 3.0.154
5. Готово! Поздравляю, Вы сэмулировали git rebase

#git #EDT

Почему это произошло и что будет дальше?

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

При этом в проектном хранилище все изменения остаются, то есть конфигурация будет Типовая конфигурация + все проектные изменения.

Следующий коммит, который будет выгружен с помощью Гитконвертера будет содержать помимо изменений этого коммита еще и все изменения, которые были сделаны раньше.
Поэтому мы в таких случаях, чтобы проверить, что все хорошо обычно просто делаем закладку в хранилище только с подъемом версии. Тогда будет четко видно, что помимо подъема версии еще приехали и все старые изменения.

В итоге получаем красивый merge или pull request в git.

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

#git #EDT