Git и Analyzer 1C: как сравнить изменения и узнать, кто изменил код 1С

Ревью задачи начинается с выбора изменений. При сравнении вершин расходящихся веток в разность попадут и правки, внесённые только в релиз. Git позволяет узнать, кто изменил конкретную строку кода. Этот разработчик и человек, который записал изменение в историю Git, могут быть разными людьми. Оба случая стоит разобрать до обсуждения качества BSL.

Для кого: разработчики 1С, которые сравнивают версии кода, ищут места вызова методов и разбираются, кто внёс изменение.

💻 Что удалось проверить на установленном Analyzer

Я запустила Docker Desktop и открыла существующий Analyzer 1C на http://localhost:8000. В шапке указана версия 2.7.65, выбрана система online-torgovlya. Контейнеры приложения и ArangoDB запустились, загруженная конфигурация осталась на месте.

В разделе «Код-ревью» видны режимы «Коммиты» и «Дельта к релизу». Отбор содержит ветку, поле «Относительно ветки», даты, автора, задачу и текст сообщения. При раскрытии отбора программа сообщила:

Лицензия не установлена. Введите строку лицензии: Настройки → Лицензия.

Это снимок текущей проверки интерфейса. Дерева изменений и результата ревью на нём нет. В журнале контейнера также указано, что базовый уровень работает без ревью. Для базового разбора в бесплатной редакции Analyzer 1C ключ не нужен: доступна одна система с неограниченным числом расширений. Сравнение версий, MCP и код-ревью относятся к дополнительным возможностям. Это указано в описании разработчика и changelog установленной поставки; сведения согласуются с текущим отказом интерфейса. Работа с графом доступна уже сейчас.

📂 Что разработчик описывает как ревью

Согласно описанию разработчика и встроенной справке Analyzer раздел собирает коммиты с отбором и показывает их деревом объектов 1С. Для метода открывается код до и после изменения. Просмотренные узлы можно отмечать; результат с замечаниями выгружается в Markdown или JSON. В нашем прогоне эти функции проверить не удалось, поэтому они описаны по документации.

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

Для работы с задачей мне нужен такой порядок:

1. Выбрать ветку и ограничить период либо номер задачи.
2. Сверить набор коммитов с составом задачи.
3. Открыть затронутые объекты и методы, прочитать код до и после.
4. Проверить последствия изменения и сформулировать замечания.
5. Сохранить результат ревью рядом с задачей.

В бесплатной редакции Analyzer 1C набор изменений я получаю средствами Git, а код и связи проверяю в доступных разделах Analyzer. Возможности лицензированного раздела перечислены выше по документации.

📊 Где вызывается метод: проверка в Analyzer 1C

Для ревью нужно найти места, где используется результат изменённой функции. Эту часть я проверила на загруженной системе online-torgovlya из расширения «УправлениеОнлайнТорговлей» 1.7.6.276. Это отдельная проверка навигации: учебный коммит про округление в эту систему не загружался.

В разделе «Граф вызовов» ввела СкрытьНастройкиАвторизации в поиск функции и выбрала результат из общего модуля CG_Online_ИнтеграцииССервисамиСервер. Затем переключила направление на «Кто вызывает» и глубину на 1. Таблица показала две процедуры, которые вызывают эту функцию напрямую: ДобавитьЗапись и ЗаписьВЛог; в каждом модуле найден один вызов.

REST-запрос вернул тот же результат. Скрипт community_probe.py выполняет GET-запросы версии, состояния редакции, поиска функции и таблицы мест её вызова. Короткий вывод фактического запуска:

1

{"version": "2.7.65", "tier": "community", "callers_total": 2}

Из сохранённого ответа /api/functions/<id>/callers/table выбраны поля имени, модуля и числа вызовов; total и truncated сохранены без изменений:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

{
  "callers": [
    {
      "name": "ДобавитьЗапись",
      "module_name": "CG_Online_ЖурналСобытийВызовСервера",
      "count": 1
    },
    {
      "name": "ЗаписьВЛог",
      "module_name": "CG_Online_ИнтеграцииССервисамиСервер",
      "count": 1
    }
  ],
  "total": 2,
  "truncated": false
}

Я сверила обе строки с исходной выгрузкой расширения:

CommonModules/CG_Online_ЖурналСобытийВызовСервера/Ext/Module.bsl, строка 70. Внешняя процедура: Процедура ДобавитьЗапись(НастройкаАвторизации = Неопределено, Уровень, ИмяСобытия, Комментарий,.

1

	CG_Online_ИнтеграцииССервисамиСервер.СкрытьНастройкиАвторизации(НастройкаАвторизации, Комментарий);

CommonModules/CG_Online_ИнтеграцииССервисамиСервер/Ext/Module.bsl, строка 19270. Внешняя процедура: Процедура ЗаписьВЛог(Знач НастройкаАвторизации = Неопределено, Процесс = "", Текст = "", Данные = Неопределено) Экспорт.

1

	СкрытьНастройкиАвторизации(НастройкаАвторизации, Текст);

На глубине 1 граф содержит выбранную функцию и две процедуры, в которых она вызывается, всего 3 узла. На глубине 5 в текущем прогоне получены 500 узлов и пометка «обрезано по лимиту». Это не полный перечень дальних зависимостей. Таблица прямых вызовов при этом содержит 2 записи; REST-ответ этой таблицы имеет truncated: false.

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

🔍 Почему важна точка сравнения

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

Само различие способов сравнения я проверила отдельно средствами Git. Скрипт probe.py создал новый учебный репозиторий без сетевых обращений. В нём исходный модуль попал в ветку release, затем появилась ветка develop. В develop изменена строка возврата, а в release добавлен отдельный файл ReleaseNote.txt. Имена участников и даты коммитов заданы для учебного примера.

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

Команда сравнения текущих состояний:

1

git diff --name-status release develop

Фактический вывод:

M	CommonModules/ReviewDemo/Ext/Module.bsl
D	ReleaseNote.txt

Вывод показал изменение BSL-модуля и удаление ReleaseNote.txt. Статус удаления относится к переходу от снимка release к снимку develop: файл существует только на первой стороне. По этой разности нельзя заключать, что разработчик удалил релизную заметку в своей задаче.

Команда сравнения от общего предка:

1

git diff --name-status release...develop

Фактический вывод:

M	CommonModules/ReviewDemo/Ext/Module.bsl

В этом выводе остался только BSL-модуль. Три точки в git diff A...B задают сравнение общего предка с B. Порядок сторон имеет значение. Синтаксис сверила с документацией git diff.

Разность модуля из этого же запуска (topic.patch):

1
2
3
4
5
6
7
8
9

diff --git a/CommonModules/ReviewDemo/Ext/Module.bsl b/CommonModules/ReviewDemo/Ext/Module.bsl
index 7d628e8..30a26a2 100644
--- a/CommonModules/ReviewDemo/Ext/Module.bsl
+++ b/CommonModules/ReviewDemo/Ext/Module.bsl
@@ -1,3 +1,3 @@
 Функция СуммаПослеСкидки(Сумма, Процент) Экспорт
-    Возврат Сумма * (100 - Процент) / 100;
+    Возврат Окр(Сумма * (100 - Процент) / 100, 2);
 КонецФункции

Это текстовый пример для сравнения истории; я не проверяла поведение функции на платформе.

🤝 Кто изменил код и кто записал изменение в Git

Для второй строки учебного модуля я выполнила:

1

git blame --line-porcelain -L 2,2 develop -- CommonModules/ReviewDemo/Ext/Module.bsl

Полный вывод для выбранной строки из файла blame.txt:

2b08a882327ebf61178ffe8fd9e1157abe88efcb 2 2 1
author Elena Example
author-mail <author@example.invalid>
author-time 1790935200
author-tz +0000
committer Integrator Example
committer-mail <integrator@example.invalid>
committer-time 1790935200
committer-tz +0000
summary TASK-42: round returned amount
previous 749c2e6c4d5288b68b1dbec1a3bc3dc8ea449b35 CommonModules/ReviewDemo/Ext/Module.bsl
filename CommonModules/ReviewDemo/Ext/Module.bsl
	    Возврат Окр(Сумма * (100 - Процент) / 100, 2);

В выводе отдельно указаны author Elena Example и committer Integrator Example. Сообщение коммита содержит TASK-42: round returned amount. Это заданные участники учебного репозитория. Фактический вывод подтверждает различие автора и коммитера.

По документации git blame, команда связывает текущие строки с изменившими их ревизиями. Она не показывает уже удалённые строки; для них нужна история изменений. Само имя в blame также не объясняет причину ошибки. Сначала стоит открыть коммит и прочитать задачу.

По описанию разработчика, Analyzer показывает, кто изменил строку кода, когда и в каком коммите; рядом указан номер задачи со ссылкой на настроенный трекер. Это пока сверка документации. Прогон blame в нашем учебном репозитории не подтверждает такую интеграцию Analyzer.

🎯 Что считать завершённым ревью

Изменённая строка задаёт место, с которого начинается проверка. Условия функции, процедуры, в которых она вызывается, и связанные метаданные могут остаться вне разности. В учебном модуле добавлено округление результата. Для оценки такого изменения понадобятся правила округления в конкретной задаче и примеры входных данных. В этом опыте BSL не исполнялся: проверялись история и разности файлов.

Справка Analyzer отдельно предупреждает о неполной истории репозитория и неразобранном составе формы. Такие предупреждения нужно сохранять в отчёте ревью. Формулировка «изменений нет» требует, чтобы нужный источник был прочитан и сравнение завершилось без ошибки.

В рабочем заключении я бы сохраняла идентификаторы сторон сравнения, состав объектов, замечания с условиями воспроизведения и результат их проверки. Номер строки полезен для перехода к коду, но после новых правок он может сместиться.

📂 Материалы и пределы проверки

Учебный скрипт создаёт репозиторий только в новом каталоге и отказывается перезаписывать существующий repo. Он сохраняет команды, коды возврата, разности файлов и вывод blame. Для запуска нужны Python 3 и Git:

1

python probe.py --out review-run

В фактическом прогоне выполнены шесть проверок состава разностей и данных об участниках коммита. Скрипт прошёл отдельную проверку. Скорость ревью и качество автоматического поиска дефектов не измерялись. Платформа 1С в этом опыте не запускалась.

Для повторения проверки в бесплатной редакции Analyzer 1C на том же составе выгрузки выполните python community_probe.py --system online-torgovlya --out community-result.json. Имя системы при другой загрузке нужно заменить. Если выбранной функции нет в исходниках, скрипт остановится на поиске: проверка относится к указанному расширению.

В архиве - скрипты, фактические выводы Git и Analyzer 1C, контрольные суммы исходных модулей и чек-лист ревью. Полная выгрузка вендорского расширения в архив не включена.

🏁 Итог

Для разбора задачи я сначала выбираю разность от подходящей точки истории, затем проверяю места вызова изменённого метода. В учебном репозитории сравнение вершин показало удаление релизного файла, которого разработчик не удалял в своей ветке; сравнение от общего предка оставило только изменение BSL. blame отдельно показал автора строки и коммитера. В установленной бесплатной редакции Analyzer 1C граф и REST показали две процедуры, в которых вызывается выбранная функция, и оба вызова совпали с исходниками расширения.

Эти результаты подтверждают выбор изменений и навигацию по связям. Для заключения о поведении BSL нужны контракт задачи и запуск на платформе. Встроенное ревью Analyzer в нашей поставке описано по документации; его исполнение в этом опыте не проверялось.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор технических публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S