Особенности использования репозитория Git для хранения технического проекта

"Классические" способы ведения групповой разработки в Git'е подразумевают, что в репозитории всегда есть основная ветка, которая называется master. Эта ветка предназначена для того, чтобы хранить версию конфигурации, в любой момент готовую к выпуску. Если в конфигурации необходимо выполнить какое-то изменение, например, исправить ошибку, для этого создаётся тематическая ветка, в которой это исправление выполняется и тестируется. Когда вы убедились, что всё работает правильно, вы сливаете основную ветку master с тематической веткой. Таким образом, в ветке master оказывается следующая работоспособная версия вашей конфигурации.

Если вы используете методику постепенного перехода на работу в 1C:EDT, когда репозиторий используется для хранения технического проекта, этот "классический" способ использования веток немного нарушается. Отличие заключается в следующем.

Ветка master используется только для того, чтобы хранить в ней актуальное состояние конфигурации основного хранилища. За это "отвечает" служебная конфигурация 1С:ГитКонвертер, которая в автоматическом режиме с некоторой периодичностью обновляет состояние ветки master (коммиты Ох1, Ох2 и т.д.). Никакие изменения разработчики в ветку master не вносят, и не сливают её с другими ветками.

Для хранения изменений проекта создаётся отдельная ветка, на рисунке она называется tech-project/000001. В этой ветке разработчики изменяют конфигурацию (коммиты Пр1, Пр2, Пр3, Пр4, Ф).

Периодически разработчики сливают ветку tech-project/000001 с веткой master, чтобы иметь у себя актуальное состояние конфигурации основного хранилища (коммиты Сл1, Сл2, СлФ).

Когда разработка проекта закончена, и он протестирован (коммит Ф), конфигурацию из ветки tech-project/000001 необходимо внести в основное хранилище. Для этого в ветку master импортируется последнее состояние основного хранилища (коммит Ох7), и ветка tech-project/000001 сливается с веткой master (коммит СлФ). Затем проект импортируется в информационную базу и переносится в основное хранилище тем способом, который описан в технологии разветвлённой разработки конфигураций, то есть так же, как если бы его разработка велась в отдельном хранилище конфигурации проекта.