Я пытаюсь найти подходящее решение для моего Git потока. Я разрабатываю структуру кода, которая состоит из:
- T- SQL хранимых процедур (1 основная процедура, которая использует все остальные)
- A python пакета, это активирует основную хранимую процедуру
Я поддерживаю несколько версий фреймворка.
Проблема в том, что я хочу создать версию хранимых процедур. Самым простым способом сделать это может быть их версия на сервере SQL, но я не знаю такой опции и не имею доступа к дополнительным инструментам.
Так что, если я ничего не пропущу, Единственный способ, которым я могу это сделать - это добавить "_v_2_0" (или любую другую версию) в конец имени процедуры. Это означает, что я добавляю этот суффикс в имя каждой хранимой процедуры, в вызовах между ними и в модуле python, который вызывает основную процедуру.
Поэтому я пытаюсь определить правильный Git flow.
Лучший вариант, о котором я подумал:
- Мастер ветвь
- Ветвь исправлений
- Разработка ветвь
- Ветвь функций
- Предварительные версии веток (1 на версию)
- Релизы веток (1 на версию)
- Как мне работать с этим:
- Regular GitFlow in master, development, исправления, ветви функций.
- Предварительные версии веток - по одной на версию, без добавления "_v_2_0" в хранимые процедуры. При фиксации исправления в одном из них - объединить каскад через все соответствующие ветки перед выпуском и мастер.
- Релизы делаются только из веток релиза, и добавление "_v_2_0" в процедуры и python появляются только в этих ветках. Эти ветви не будут объединены с другими, и будут получать слияния только из соответствующих веток перед выпуском.
Предостережение заключается в том, что теги не отображаются в основной ветке, т. Е. Нет доступа к окончательным версиям из главной.
Некоторая дополнительная информация: я главный разработчик, но у меня есть несколько сотрудников, занятых неполный рабочий день, поэтому поток Git должен быть подходящим для команды.
Это тоже правильный путь? Это кажется сложным, но я не могу придумать лучшего способа.
Спасибо!