Возможно, это связано с быстрой пересылкой. Если Git не нужно делать слияние, это не будет. Это происходит, когда вы объединяете ветку, но не внесли никаких изменений в ее родительский элемент.
A - B - C - D - E [master]
\
F - G - H [feature]
В этом репо не было никаких изменений в master
поскольку feature
было ветви. master
является предком feature
. Эта очевидная ветвь между E и F на самом деле не существует, история прямая.
Если вы git checkout master; git merge feature
, это будет «перемотка вперед», и вы закончите с этим.
[master]
A - B - C - D - E - F - G - H [feature]
master
перемещается к тому же, как совершить feature
, не слияние не будет сделано.
Вы можете отключить это с помощью git merge --no-ff
. Я рекомендую это при объединении ветвей функций, чтобы избежать потери важной информации для понимания кода. В приведенном выше примере нет никаких доказательств того, что F, G и H были выполнены как одна особенность. Нет ссылки на билет, обсуждающий эту функцию.
Вместо этого, если бы у нас было git checkout master; git merge --no-ff feature
, это заставило бы Git объединиться, даже если это не обязательно.
A - B - C - D - E ---------- I [master]
\ /
F - G - H [feature]
Я являюсь слиянием, и вы получаете хороший пузырь функций.
Я думаю, что слияние является быстрым слиянием. То, что вы ожидали, является истинным слиянием. В вашем случае ускоренное слияние - это поведение по умолчанию, когда это возможно. Конец, на который указывает 'master', является предком фиксации, на которую указывает' my-branch'. Вы могли бы добавить '--no-ff' (что означает * без быстрого слияния) для принудительного применения истинного слияния. – ElpieKay