Слияние с другой веткой функций перед переходом на Master в Git

Question

Итак, я пытаюсь понять, как Git обрабатывает определенные процессы и каковы некоторые из уже используемых практик.

Допустим, у нас есть Git-репозиторий с веткой с именем master. У нас также есть две ветви, которые создаются одновременно из master. Мы назовем их branch_one и branch_two.

branch_one уже завершена работа для определенной функции. В настоящее время я работаю над branch_two. Ради этого разговора давайте предположим, что я не могу объединить branch_one с master, потому что он ожидает одобрения от других разработчиков.

Вот проблема:

Мне нужна вся работа с branch_one, чтобы перейти к branch_two.

Вот мой текущий поток:

1) объединить branch_one в branch_two.
2) работа на branch_two.
3) перед отправкой запроса на подтягивание branch_two с master.

Ой-ой. Ребаз имеет конфликты на 30+ патчей. Я предполагаю, что это потому, что слияние (шаг 1) изменяет заголовок branch_two. Я могу предположить, что неправильно.

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

Итак, мои вопросы:

Есть ли лучший способ обработать процесс такого типа, когда ветвь функции требует изменений из другой ветви функции, которая не включает массовых конфликтов?

Answer 1

Вам нужна ветка интеграции, сделанная из master HEAD:

• объединить ветку1 в интеграцию
• rebase branch2 поверх интеграции.

Если branch1 требует дополнительной работы в контексте его проверки, объедините новые коммиты branch1 в интеграцию снова.
В какой-то момент branch1 будет объединен с master.

Затем, когда вы захотите проверить Branch2, сначала перебазируйте его поверх обновленной ветви интеграции. Затем объедините его с интеграцией (используя --no-ff: без объединения с ускоренной перемоткой вперед).

Наконец, объедините branch2 с master, когда будете готовы. Там нет конфликта.

Подробнее об этом рабочем процессе см. Gitworkflow (намного лучше, чем Gitflow )

Answer 2

Вы попали в общую ловушку в GIT.Решение всегда, думайте заранее.В вашем сценарии знание того, понадобится ли вам функция из одной ветви раньше времени, даст вам возможность ветвиться таким образом, чтобы избежать этой проблемы:

создайте ветку от мастера, которая будетэпическая ветвь

git checkout -b epicBranch

создать оба branch_one & branch_two из epicBranch

git checkout -b branch_one git checkout -b branch_two

Как только вам понадобится функция из branch_one вашего PR и объедините branch_one в epicBranch, затем объедините epicBranch в branch_two

git checkout branch_two
git merge epicBranch

Теперь у вас есть изменение с branch_one в branch_two без накладных расходов на закрытие веток.

У вас будет история коммитов, и вы не должны столкнуться с какими-либо проблемами при слиянии или перебазировании.

Вы также можете сэкономить много головной боли, выбрав нужную фиксацию функции в своей собственной ветви, которую можно разделить между ветками.