Git продвижение / слияние подход со сторонним продуктом

Question

Я понимаю, что это очень специфический вопрос, и некоторые вещи могут даже вздрогнуть даже закаленного пользователя git, но потерпите меня…

Мы реализуем виртуальное хранилище данных, которое генерирует метаданные (SQL-подобный код). Продукт ( Denodo) можно подключить к VCS (например, git), чтобы сохранить изменения под контролем версий.

Внутри есть виртуальные базы данных, и Denodo также организует свой код в папки, соответствующие этим базам данных. Таким образом, в git вы получите что-то вроде:

Root
 \- Orders
 \- Customers
 \- Invoices

Под каждой из этих папок базы данных будет несколько файлов кода, которые составляют метаданные.

Фиксация и отправка вашего кода в Denodo всегда выполняется на уровне базы данных, даже если git-репо не имеет такого различия, а фиксация является глобальной для репо.

Разработчики работают локально над своими отдельными базами данных и будут периодически вносить изменения в код. Все эти изменения перенесены на сервер разработки. Все идет нормально.

Рано или поздно изменения, внесенные в разработку, должны найти свое отражение в обеспечении качества и производстве. Однако, если мы должны были объединить текущий статус из нашей ветки разработки (develop) в нашу ветку QA (release), мы можем получить некоторые нежелательные (ломающиеся) изменения, которые еще не были готовы к прайм-тайму.

Таким образом, нам нужно вишня. И используя git log, мы можем видеть, какие коммиты еще предстоит повысить до QA. Но если мы выберем отдельные коммиты из develop ветвь в release филиал, они получат новый SHA, и в следующий раз мы сделаем git log чтобы выполнить сравнение, ранее выбранные вишни коммиты все равно появятся.

Также помните, что хранилище организовано по базе данных. Это также означает, что:

• Я сообщаю о коммитах, сделанных в каждой папке, связанной с базой данных
• Определите последний коммит для каждой базы данных для продвижения
• Для каждой базы данных: выберите наиболее старый коммит с момента последнего слияния до того, который был выбран на предыдущем шаге.

Этот диапазон не обязательно является последовательным. У вас может быть что-то вроде этого (упорядочено по дате).

| To be promoted | Commit | Database  | Change              |
|----------------|--------|-----------|---------------------|
|                | da39a3 | Orders    | Created views       |
|        X       | ee5e6b | Customers | Bug fix             |
|        X       | 4b0d32 | Invoices  | Removed data source |
|                | 053e2d | Invoices  | Updated credentials |
|        X       | 956018 | Orders    | Created data source |

В этом примере мы бы выбрали коммиты ee5e6b (клиенты), 4b0d32 & 053e2d (счета) и 956018 (заказы). Причину, которую я должен выбрать 053e2d для заказов также, что последние метаданные могут основываться на ранее внесенных изменениях (из-за зависимостей внутри базы данных). Между базами данных мало или вообще нет никаких зависимостей.

Требования:

• Каждый раз, когда планируется продвижение по службе, я должен иметь возможность представить обзор коммитов, которые находятся в разработке, но не в QA.

• Я должен иметь возможность выбирать определенные изменения (вплоть до) на уровне базы данных, которые могут быть объединены с release ветка для продвижения в QA.

Ограничения:

• Коммиты происходят изнутри Denodo, и поддержка VCS не так уж велика (например, изменение веток не поддерживается). Это также означает, что мы не можем реализовать функциональные ветви, чтобы изолировать критические изменения или долгосрочное развитие.

• Хотя мы оцениваем, что продвигать на уровне базы данных, эти коммиты не являются последовательными.

Приношу свои извинения за многословный вопрос, но это не совсем типичный сценарий и требует немного больше контекста. Я также не специалист по мерзавцам (не слишком далеко), поэтому, пожалуйста, никаких вил или факелов. Спасибо!