8 фишек проверки подрядчика 1С по Git-репозиторию

📅 Опубликовано 10 августа 2026 г.

Коротко: Git-репозиторий подрядчика 1С показывает то, чего не покажут ни презентация, ни отзывы: кто реально писал код, как часто, насколько аккуратно и что останется у вас после расставания. Проверка занимает 30–40 минут и не требует навыков программирования — достаточно открыть историю коммитов в веб-интерфейсе GitHub, GitLab или Bitbucket и пройти по восьми пунктам ниже. Каждый из них закрывает конкретный риск: от «ушёл один человек — встал проект» до штрафа за утечку персональных данных.

Ритм важнее объёма. Здоровый проект даёт коммиты в 60–80% рабочих дней; один коммит раз в 2–3 месяца означает, что доработки живут в базе клиента, а не в репозитории.
Один автор — главный риск. Если 90% изменений сделаны с одного аккаунта, «команда из 15 специалистов» на сайте существует только на сайте.
Формат хранения решает всё. Конфигурация, выгруженная в файлы (XML) или проект EDT, читается построчно; репозиторий из cf- и dt-файлов не даёт ни истории, ни сравнения версий.
Секреты в репозитории — красный флаг. Пароли подключения, выгрузки с ФИО и зарплатами, ключи ЭДО в открытом виде — это готовый инцидент по 152-ФЗ, причём уже на вашей стороне.
Право доступа прописывается в договоре. Формулировка «исходные коды передаются в репозиторий заказчика не реже одного раза в неделю» стоит дороже любых устных обещаний.

Почему история коммитов честнее презентации подрядчика?

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

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

Что смотрим	Здоровый признак	Тревожный сигнал	Чем рискует заказчик
Частота коммитов	Изменения в 60–80% рабочих дней	Один коммит раз в 2–3 месяца	Доработки живут только в базе, откатиться некуда
Комментарии	«Исправлен расчёт НДФЛ по договорам ГПХ»	«фикс», «11», «.», «тест»	Через год никто не поймёт, что и зачем меняли
Состав авторов	3–8 постоянных участников	90% изменений с одного аккаунта	Уход одного человека останавливает проект
Ветки и релизы	Ветки под задачи, теги версий	Только master без тегов	Нельзя выпустить срочное исправление отдельно от сырых доработок
Содержимое	Исходники, документация, скрипты	dt-файлы, пароли, выгрузки с ФИО	Утечка персданных, риски по 152-ФЗ

Фишка 1. Как читать частоту и ритм коммитов?

Откройте вкладку «Insights» → «Commits» (GitHub) или «Аналитика» → «Репозиторий» (GitLab). Вы увидите столбчатый график активности по неделям за год. Смотреть нужно не на общее количество, а на равномерность. Живой проект сопровождения даёт всплески перед отчётными периодами (январь, апрель, июль, октябрь) и провалы в отпускной сезон — это нормальный ритм бухгалтерского цикла.

Что должно насторожить. Первое — «стена» из сотен коммитов в один день и пустота вокруг: обычно это разовая заливка чужого кода в репозиторий для показа. Второе — активность, которая обрывается 4–6 месяцев назад: команду либо расформировали, либо клиент ушёл, а витрину оставили. Третье — коммиты, сделанные исключительно ночью и в выходные: у подрядчика ваш проект будет побочной подработкой, а не основной загрузкой, и любая срочная ошибка в закрытии месяца повиснет до вечера.

Полезный ориентир: для команды из 3–5 разработчиков нормой считаются 40–120 коммитов в месяц на активный проект. Меньше 10 — сопровождение формальное, больше 300 — либо в репозиторий пишут автоматические выгрузки, либо изменения дробятся до бессмысленности.

Фишка 2. О чём говорят комментарии к коммитам?

Комментарий к коммиту — это то, что через два года прочитает следующий подрядчик, разбирая ваши доработки. Откройте список коммитов и прочитайте подряд 30–40 последних сообщений. Хороший комментарий отвечает на вопрос «зачем», а не «что»: «Добавлен признак раздельного учёта НДС в реализацию по 44-ФЗ», «Исправлено дублирование строк в отчёте по остаткам при указании склада». Плохой — «правки», «фикс2», «работа за вторник», «ыыы».

Отдельно ищите ссылки на номера задач вида #412 или SD-1180. Их наличие означает, что у подрядчика есть трекер задач и каждое изменение кода связано с заявкой заказчика. Это ровно тот механизм, который потом позволяет вам оспорить счёт: «покажите, какие изменения были сделаны по заявке №118 за 12 часов». Если связи «заявка → изменение» нет, акт выполненных работ будет строиться на честном слове.

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

Фишка 3. Сколько реальных людей в команде подрядчика?

Это самая недооценённая проверка. На сайте франчайзи может быть заявлено «более 40 сертифицированных специалистов», а во вкладке «Contributors» вы увидите трёх человек, один из которых сделал 94% изменений. В GitLab тот же срез доступен в разделе «Участники» и в аналитике вклада; в консоли это одна команда — git shortlog -sn.

Что считать нормой: для проекта внедрения ERP — 4–10 активных авторов, для сопровождения бухгалтерии небольшой компании — 2–3. Опасны две крайности. Первая — «человек-оркестр»: все ключевые модули писал один разработчик, и его увольнение или болезнь превращают ваш проект в археологию. Вторая — «карусель»: за год через репозиторий прошли 15 разных авторов, каждый сделал по 5–10 коммитов и исчез. Это текучка, при которой преемственность знаний по вашей базе не удержится.

Посмотрите и на почтовые домены авторов. Если половина коммитов сделана с адресов на бесплатных почтовых сервисах и никнеймов вроде dev-1c-2, скорее всего, подрядчик перепродаёт работу субподрядчикам. Само по себе это не преступление, но должно быть отражено в договоре — вместе с ответственностью за конфиденциальность. Часть таких сигналов пересекается с другими скрытыми признаками недобросовестного франчайзи, и лучше проверять их в комплексе.

Фишка 4. В каком формате подрядчик хранит конфигурацию 1С?

Здесь начинается специфика 1С, которой нет в обычной разработке. Конфигурацию можно положить в Git тремя способами, и они дают принципиально разный результат.

Выгрузка в файлы (XML). Конфигуратор раскладывает конфигурацию на тысячи текстовых файлов — по объекту метаданных на файл. Git видит изменения построчно: можно сравнить две версии реквизита, найти, кто и когда убрал проверку в проведении документа. Это рабочий минимум.
Проект 1C:EDT. Современный вариант с тем же результатом, но удобнее для командной разработки и ветвления. Признак — папки src, файлы DT-INF, .project в корне.
Файлы cf, cfe, dt целиком. Формально репозиторий есть, фактически это шкаф с архивами: Git хранит бинарные файлы, сравнить версии нельзя, история бесполезна, а размер репозитория растёт на сотни мегабайт с каждой выгрузкой.

Отдельный плюс — если доработки лежат в виде расширений (cfe в исходниках), а типовая конфигурация не тронута. Это прямо влияет на ваши расходы: снятая с поддержки типовая конфигурация превращает каждое обновление в проект на 20–60 часов вместо получаса. Спросите прямо: «Какая доля доработок сделана расширениями?» — и сверьте ответ со структурой папок в репозитории.

Фишка 5. Есть ли ветки, теги и релизы — или всё свалено в master?

Вкладка «Branches» показывает, как команда управляет параллельной работой. Если веток две-три и они называются feature/zarplata-gph, hotfix/ndfl-2026, release/1.2 — процесс есть. Если ветка одна и в неё пишут все — любое изменение любого разработчика немедленно попадает в общий контур, и выпустить срочное исправление, не потянув за собой чужие недоделанные доработки, невозможно.

Дальше смотрите «Releases» или «Tags». Теги вида v2.4.1 с датами — это версии, которые ставились в продуктив. Их наличие означает, что подрядчик умеет отвечать на вопрос «что именно работало в базе 15 марта, когда сформировалась некорректная декларация». Без тегов реконструкция состояния базы на конкретную дату превращается в расследование на несколько часов, оплаченных вами.

Ещё один индикатор — «Pull requests» / «Merge requests». Если они есть и в них видны комментарии коллег («тут не учтён случай с обособленным подразделением»), значит, в команде есть код-ревью: чужие ошибки ловят до попадания в вашу базу. Практика показывает, что ревью снижает долю повторных обращений по одной и той же доработке примерно вдвое.

Фишка 6. Что лежит в репозитории лишнего?

Пройдитесь по корню репозитория и по истории поиском слов password, пароль, connect, backup. Вы ищете три категории мусора.

Секреты. Строки подключения к базам, пароли пользователей 1С, логины к сервисам ЭДО и маркировки, токены API банков. Опасность в том, что Git помнит всё: даже если файл удалили следующим коммитом, пароль остаётся в истории навсегда.
Персональные данные. Тестовые выгрузки с реальными ФИО, паспортами, окладами, файлы zarplata_test.xlsx. Это чужие персданные в открытом или полуоткрытом репозитории — то есть подрядчик уже допускал утечку у другого клиента, и с вами поступит так же.
Технический балласт. Гигабайтные dt-выгрузки, папки Новая папка (2), установочные дистрибутивы платформы. Показывает общий уровень аккуратности.

Наличие файла .gitignore с исключениями для временных файлов, логов и выгрузок — маленький, но надёжный признак культуры. Отсутствие — почти гарантия, что в репозитории рано или поздно окажется что-то, чего там быть не должно. Если планируете передавать сопровождение целиком, порядок в чужих репозиториях стоит проверить до того, как отдавать 1С внешней команде на аутсорс.

Фишка 7. Как быстро подрядчик реагирует на задачи и ошибки?

Если репозиторий публичный или полупубличный, откройте «Issues». Вас интересуют не открытые задачи, а закрытые: сколько времени прошло между созданием и закрытием. Отфильтруйте is:issue is:closed и посмотрите 20 последних.

Ориентиры по рынку сопровождения 1С: критичная ошибка (не проводится документ, не формируется отчётность) — реакция в течение 2–4 рабочих часов, решение в течение рабочего дня; обычная доработка — от 3 до 10 рабочих дней в зависимости от объёма. Если в истории видно, что задачи висят открытыми по 4–8 месяцев, а затем закрываются пачкой без комментариев в конце года — это «уборка» перед отчётом, а не работа.

Смотрите и на то, кто отвечает. Если во всех обсуждениях участвует только менеджер, а разработчик молчит, вы получите испорченный телефон: бухгалтер объясняет менеджеру, менеджер — разработчику, и на выходе получается не то, что просили. Здоровый паттерн — уточняющие вопросы от исполнителя прямо в задаче: «В какой момент должна пересчитываться сумма — при проведении или при записи?»

№	Что проверяем	Где смотреть	Время
1	Ритм коммитов	Insights → Commits, график активности	3 мин
2	Качество комментариев	Список коммитов, последние 30–40	5 мин
3	Реальный состав команды	Contributors / Участники	3 мин
4	Формат хранения конфигурации	Структура папок в корне	4 мин
5	Ветки, теги, релизы	Branches, Tags, Releases	4 мин
6	Секреты и персданные	Поиск по репозиторию и истории	7 мин
7	Скорость закрытия задач	Issues, фильтр закрытых	6 мин
8	Документация и README	Корень репозитория, папка docs	5 мин

Фишка 8. Есть ли документация и инструкция по развёртыванию?

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

Дальше ищите папку docs или Документация. Хороший подрядчик держит там описание доработок в терминах бизнеса: какой документ изменён, какой реквизит добавлен, как проверить результат в интерфейсе. Плохой — не держит ничего, потому что документация делает его заменяемым, а незаменимость и есть его бизнес-модель.

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

Найдите специалиста для решения этой задачи на koderion.ru