Репозиторий как единый источник истории
Проект помещают в Git-репозиторий и договариваются, какие файлы должны отслеживаться, а какие являются локальными или генерируемыми. Важна дисциплина небольших коммитов: один коммит лучше посвящать одной логической задаче. Сообщение должно объяснять смысл изменения, а не просто повторять название файла. Такая история помогает разбирать регрессии и возвращаться к рабочему состоянию. Чем крупнее и смешаннее коммит, тем сложнее понять, какая именно часть вызвала проблему.
Ветки и изоляция задач
Для новой функции или исправления удобно создавать отдельную ветку. Разработчик меняет код, проверяет проект и только после этого объединяет работу с основной линией. Ветка не должна жить бесконечно: чем дольше она расходится с основой, тем больше вероятность сложных конфликтов. Поэтому полезно регулярно подтягивать актуальные изменения и держать задачу достаточно небольшой. Если функция занимает недели, её можно разбить на независимые этапы, каждый из которых проходит отдельное ревью.
Конфликты в метаданных
В 1С конфликт может возникнуть не только в тексте модуля, но и в описании объектов метаданных. Два разработчика способны одновременно изменить одну форму, реквизит или структуру объекта. Автоматическое слияние не всегда понимает бизнес-смысл. Конфликт нужно разбирать вручную: выяснить намерение обеих сторон, выбрать корректную комбинацию и затем открыть проект в EDT для проверки структуры. Простое удаление маркеров конфликта ещё не гарантирует, что конфигурация стала логически целой.
Код-ревью и проверка перед слиянием
Pull request или аналогичный процесс полезен даже для небольшой команды. Ревьюер смотрит не только синтаксис, но и влияние на архитектуру, читаемость, дублирование и возможные побочные эффекты. Перед слиянием стоит убедиться, что проект собирается, проверки проходят, а ветка не содержит случайных файлов. Хорошая практика — отделять форматирование и механические изменения от функциональных, иначе полезный код теряется среди сотен несущественных строк.
Попробуйте на практике
Организовать учебный цикл изменения через Git.
- Создайте отдельную ветку от основной ветки проекта.
- Внесите одно небольшое изменение в модуль и сохраните его отдельным коммитом с понятным описанием.
- Сымитируйте параллельное изменение той же строки в другой ветке и выполните слияние.
- Разрешите конфликт вручную, затем проверьте проект в EDT и просмотрите итоговый diff.
Как проверить результат. Упражнение выполнено, если история содержит понятные отдельные коммиты, конфликт разрешён осознанно, а итоговый проект открывается без структурных ошибок.
Частые вопросы
Зачем Git, если есть резервные копии базы?
Резервная копия возвращает состояние целиком, а Git показывает историю отдельных изменений, позволяет сравнивать версии, работать ветками и объединять вклад нескольких разработчиков.
Нужно ли создавать ветку для каждой мелочи?
Для самостоятельных логических изменений это удобно. Совсем небольшие технические правки команда может обрабатывать проще, если правила заранее согласованы.
Можно ли автоматически принимать конфликт при слиянии?
Иногда, но для метаданных это рискованно. Нужно понимать смысл обеих версий и обязательно проверять проект после разрешения конфликта.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.