Я признаю, что есть подобные вопросы, которые были заданы и даны ответы здесь. Поскольку ни один из них не дает мне однозначных ответов, я подумал снова задать этот вопрос. Надеюсь, вы не отклоните этот вопрос. С учетом сказанного:
Сценарий
У нас есть ветка разработчика Bitbucket, в которой хранится контент, связанный с указанным c релизом (Давайте назовем ветку dev-release-1 ). Поскольку работа над следующим выпуском начинается до того, как текущим выпуском будет GR, мы создали еще одну ветку для следующего выпуска (назовем эту ветку dev-release-2 ). Это означает, что некоторые люди продолжают работать над dev-release-1 , работая над новой веткой. В новой ветке также должны быть внесены изменения в текущей ветке релиза. Изменения в ветке dev-release-1 минимальны, и мы хотим избежать полного слияния dev-release-1 в dev-release-2 .
Вопросы
- Является ли вишневый пик хорошим вариантом для этого сценария? Я попробовал это в нашей песочнице. Вид работ. Не уверен, если это вызовет много конфликтов, когда мы объединяем все ветви в мастер. Поскольку cherry-pick приводит к совершенно новому идентификатору коммита, я не уверен в этом.
- Является ли применение исправления хорошим вариантом? Пробовал и это тоже. Сравнительно проще это сделать с помощью sourcetree. Поскольку это приводит к совершенно новому идентификатору фиксации, я не уверен в этом.
- Есть ли возможность объединить один коммит из одной ветви в другую без изменения идентификатора фиксации?