(Как уже отмечали несколько человек, в Git не существует такой вещи, как частичное слияние.)
Я не являюсь автором оригинальных сообщений в блоге и не могу говорить за него, но скажу, чтов общем он прав.Вдохновляющий пример немного глупый, но это почти неизбежно, когда кто-то пытается сделать простой пример того, почему мы можем сделать что-то, что выглядит сложным.
Если вы заранее знаете, что некоторые изменения необходимо применить кВ нескольких ветвях (и использующих Git) вы можете вернуться к самому раннему коммиту, в котором можно внести изменение, которое, согласно нашему определению «будет применено», будет до того, как другие ветки ответвляются от этого коммита.- и сделайте новую ветвь с этой точки.Затем вы можете внести изменения и зафиксировать.Это создает ветку patch (см. Диаграмму, которую мистер Чен показывает в третьем посте, которую вы скопировали в вопрос).
Затем вы можете объединить эту новую ветку со всеми другими ветками, как показано здесь.(и там).
Но это подразумевает, что мы заранее знаем, что изменение также должно быть в мастере.
Правильно.Чтобы использовать эту стратегию, мы должны знать, что этому конкретному патчу суждено войти в некоторый набор N ветвей и найти подходящий коммит предков, который содержится во всех них.
В посте не объясняется, что делать, если изменение первоначально зарегистрировано в ветви функций, и только позже мы обнаруживаем, что оно должно быть также в [другой] ветви.
Нет идеального решения для этого, но есть достаточно хорошее.Это нарушает вашу жалобу, хотя:
Что делать тогда?Как объединить только это изменение с [другой веткой]?Не собирайте вишню, пожалуйста.
То, как мы это делаем, заключается в том, чтобы идентифицировать этот предковый коммит - где бы он ни был - и сбор вишни.(Извините!) Cherry-pick создает один новый коммит, который находится исключительно в ветке патча.Затем мы объединяем ветку патча в обе ветви, как если бы мы сделали правильную вещь в первый раз.Это приводит к следующему:
(apple) (berry)
M1---------M2 <-- master
/ /
A----------P' <-- patch
\ \
F1------P--F2 <-- feature
(apple) (berry)
Обратите внимание, что объединение patch в feature не оказывает влияния на дерево исходных текстов в коммите F2 на feature: дерево исходных текстовв F2 совпадает с оригинальным патчем P.Это верно, даже если есть коммиты feature после P, например:
M1---------M2 <-- master
/ /
A----------P' <-- patch
\ \
F1--P--Q---F2 <-- feature
При необходимости мы можем выполнить слияние в feature с -s oursчтобы избежать «отмены» каких-либо изменений или получения какого-либо конфликта слияния. Смысл выполнения этого слияния с feature состоит в том, чтобы Git осознал тот факт, что общий предок master и feature теперь является коммитом P'. Commit P' должно существовать , даже если мы должны создать его только для этой цели.Самый простой способ до создать это - использовать git cherry-pick.
Сбор вишни - это инструмент, а не решение.В сообщении г-на Чена говорится, что люди плохо используют инструмент.Это не значит, что инструмент сам по себе плохой!