Шеф-повар выпускает поваренную книгу из предыдущей ветки git

Question

У меня есть несколько кулинарных книг CHEF, которые я использую. Каждый из них версируется в соответствии с семантическим версированием.

Моя производственная среда использует поваренной 0.1.1
Мой этап среды с использованием поваренной книги 0.2.0

Версия 2.0 имеет большое изменение, которое я не могу развернуть в производство еще. Обнаружена ошибка, которая должна быть скопирована в 0.1.x. Как мне создать и развернуть поваренную книгу 0.1.2 для производства, не сливаясь с большими изменениями в кулинарной книге 2.0 в производство?

Использование git-flow. Новые выпуски создаются у ветви разработки. Затем слились обратно в разработку и тестирование. После тестов он затем объединяется для мастеринга, с учетом тега git и автоматически развертывается на сервере шеф-повара.

0.1.1    0.2.0 
/ \   / \ 
o-o--------o-o---X---o--------o-o-------- develop 
\   \     \ 
    o------------o------------------o------ master 

Когда поваренная книга отпущена, ветвь освобождения удаляется.

Я предполагаю, что мне нужно проверить X, а затем создать поваренную книгу 0.1.2. Однако, когда я пытаюсь объединить поваренную книгу 0.1.2 в ветку разработки, у metadata.rb и CHANGELOG.md есть конфликты слияния (Y). В то время как я мог переустанавливать до, была выпущена поваренная книга 0.2.0, которая изменила бы мою всю историю.

      _________________ 
         /    \ 
    0.1.1   0.1.2  0.2.0   \ 
/ \  /  / \  \ 
o-o--------o-o---X---------o--------o-o------Y-- develop 
\   \      \ 
    o------------o------------------------o------- master 

Что лучший способ развернуть старую поваренную книгу?

Я знаю, что подобные вопросы по поводу обратных git-коммитов были запрошены на SO, но никто из них не описывает, как справиться с неизбежными конфликтами слияния. Должен ли я просто признать, что будут конфликты и разрешить их вручную?

• How do I backport a commit in git?

• Git strategy to backport bugfixes into older branches (cherry-pick vs. merge)

• http://glicksoftware.com/blog/backporting-a-topic-branch-with-git

Update

Чтобы уточнить, у меня уже есть Стра для использования разных кулинарных книг в разных средах с использованием файла environment.json и version pinning.

Answer 1

Так два несвязанных вопросы здесь:

Во-первых, как управлять ветви обслуживания при ГИТ-потока. Мне не нравится их структура, но я думаю, что главным образом официальный способ состоит в том, чтобы создать новую ветку из существующего тега, внести изменения, пометить выпуск обслуживания, а затем объединить эту ветвь для управления.

Во-вторых, как сделать управление выпуском в шеф-поваре. Как правило, это делается в среде шеф-повара. Каждая среда может иметь набор ограничений, какие версии каждой кулинарной книги разрешены в этой среде. Вы должны установить ограничение на производство на ~> 0.1.0, поэтому релиз обслуживания разрешен, но не новая младшая версия. Тем не менее, в соответствии с SemVer (и связанным с ним), вы должны использовать основные версии для указания перерывов между партнерами.

Answer 2

Git flow «support branches», как предложено @StephenKing, является ответом на проблему git и частью решения проблемы развертывания шеф-повара.

То, что я в конечном итоге делает:

Создание нового GIT филиал под названием «Поддержка/1,0»

Применить мое исправление для этой отрасли, а затем изменить metadata.rb и CHANGELOG.md к v0.1.2 и добавить тег git.

Затем я объединил эту ветку в мастерскую, пропустив ее (Z). У meatadata.rb и CHANGELOG.md были конфликты, которые я разрешил вручную. Затем Дженкинс загрузил поваренную книгу 0.1.2 на сервер шеф-повара.

Удалить ветвь поддержки/1.0.

     v0.1.2_________________ 
        /      \ 
    0.1.1  support/1.0  0.2.0  \ 
/ \ /   / \  \ 
o-o--------o---X----------------o-------o--------\-- develop 
\   \       \  \ 
    o----------o----------------------------o--------Z- master 

Pros этому подходу:

• Нет долго не живет Поддержка отделения
• Еще есть поваренная книга в системе управления версиями с мерзавца тегом
• Не было перебазировать истории

Против

• Мастер филиал будет продолжать показывать старую версию до следующей версии

Разработка metadata.rb = "0.2.0"
Master metadata.rb = "0.1.2"

Когда версия 0.2.1 будет выпущена, metadata.rb в обоих ветвях покажет правильную последнюю версию. До тех пор это потенциально могло бы запутать людей, чтобы думать, что 0.1.2 является последней поваренной книгой.