Базовый процесс 1С‑разработчика: EDT + Git без хаоса
Чтобы работать с EDT и Git правильно, держите правило: 1 задача = 1 ветка = понятные коммиты + Merge Request с ревью, а основная ветка (main) всегда остаётся стабильной. Ниже — минимальный командный процесс, который можно внедрить в команде сразу.
Оглавление
Что настроить один раз
1) Репозиторий хранит “только исходники”. EDT ведёт проект в файловом виде (метаданные/модули), поэтому заранее приведите в порядок:
.gitignore— исключить служебные файлы рабочей области/кэши;.gitattributes— зафиксировать окончания строк и правила текста, чтобы не ловить массовые “переезды” файлов.
Если у части команды CRLF, а у части LF, Git будет показывать «изменилось всё». Зафиксируйте правила в .gitattributes до активной разработки.
2) Договоритесь о ветках (минимум).
main— стабильно, напрямую не пушим.feature/…— ветка под задачу.hotfix/…— срочная правка отmain.
3) Привязка “ветка → своя ИБ”. В EDT удобно держать отдельную информационную базу (или вариант запуска) под ветку: меньше “у меня работает, у тебя нет” при переключениях.
Ежедневный цикл: ветка → коммиты → MR
Шаг 1. Обновитесь от main перед работой
git checkout main
git pull
Шаг 2. Создайте ветку под задачу
git checkout -b feature/TASK-123-short-name
Шаг 3. Делайте изменения маленькими порциями Практика, которая реально упрощает ревью и слияния:
- один логический кусок = один коммит;
- перед коммитом проверьте: проект собирается, вы понимаете каждое изменение в diff.
Шаг 4. Коммит с нормальным сообщением
git add -A
git commit -m "TASK-123: Исправил расчет НДС в Реализация"
Шаг 5. Отправьте ветку и откройте MR/PR
git push -u origin feature/TASK-123-short-name
В описании MR обязательно: что сделано, как проверить, риски (перепроведение, права, обмен).
Самая полезная строка в MR для 1С — “Как проверить”: 3–6 шагов, чтобы любой коллега воспроизвёл результат в своей ИБ.
Шаг 6. Регулярно подтягивайте изменения из main
Выберите один подход на команду:
merge main— проще и “не переписывает историю”;rebase main— линейная история, но требует дисциплины.
Слияния и конфликты в EDT
Золотое правило: конфликты решаем “по смыслу”, потом проверяем сборку и минимальный сценарий в ИБ.
Быстрый алгоритм, если конфликт в модуле
- Открыть конфликт и понять, что меняли обе стороны.
- Собрать итоговую версию вручную.
- Проверить компиляцию/запуск критичного сценария.
- Завершить merge/rebase и закоммитить результат.
Если конфликт в метаданных (форма/объект)
- сначала восстановите “что должно быть” (реквизиты, команды, обработчики);
- затем откройте форму в режиме предприятия и проверьте ключевое действие пользователя.
Короткая памятка по командным правилам
| Ситуация | Как правильно | Как не надо |
|---|---|---|
| Начали задачу | Новая feature/* | Несколько задач в одной ветке |
| Отправка на проверку | MR/PR + шаги проверки | “Посмотри” без контекста |
| Слияние | Только через MR, без прямых push в main | Мержить в main руками |
| “Горячие” объекты | Предупреждать и чаще синхронизироваться | Неделями жить в своей ветке |
Частые ошибки
- Один коммит на сотни файлов из‑за форматирования EDT. Решение: чаще смотреть
git diff, коммитить небольшими порциями, унифицировать настройки/версии EDT. - Долгая жизнь ветки без синхронизации с
main. Решение: подтягиватьmainежедневно (или чаще), иначе конфликтов будет кратно больше. - Смешали рефакторинг и бизнес‑правку. Решение: два MR — “рефакторинг без изменения поведения” и “функциональные изменения”.
- Прямой пуш в
main. Решение: защита ветки + правило “только через MR”.
FAQ
Нужно ли делать отдельную ИБ на каждую ветку?
Желательно да: меньше побочных эффектов при переключении, проще воспроизводить ошибки и проходить ревью.
Что выбрать: merge или rebase?
Для старта проще merge main в feature‑ветку. rebase подключайте, когда команда готова соблюдать правила (и не переписывать историю веток, которые уже ревьюят несколько человек).
Можно ли работать без MR/PR, если команда маленькая?
Не стоит: MR — это не бюрократия, а контроль качества (контекст, шаги проверки, история изменений) и защита main от случайных поломок.