Каков наилучший способ git patch поддиапазона ветки?

Question

В Subversion легко объединить диапазон наборов изменений / различий из ветви, используя "svn merge -r a: b mybranch". Но в git я обнаружил, что можно выбрать только один коммит из ветки, чтобы применить этот патч к моей текущей рабочей ветке. Поэтому мне интересно, есть ли быстрый способ применить все коммиты одним махом между двумя тегами в ветви исправлений к моей текущей основной ветви?

Answer 1

Самый простой способ выполнить искомое действие - git rebase. Вот рецепт. Предположим, что тег A - это фиксация, поверх которой основана серия патчей, которую вы хотите выбрать, а тег B - это фиксация последнего патча в серии. Также предположим, что br - это имя текущей ветви и ветви, к которой следует применить новую серию патчей.

# Checkout a new temporary branch at the current location
git checkout -b tmp

# Move the br branch to the head of the new patchset
git branch -f br B

# Rebase the patchset onto tmp, the old location of br
git rebase --onto tmp A br

Answer 2

Я нашел самый простой способ сделать это:

git cherry-pick starthash..endhash

обратите внимание, что две точки не имеют пробелов, отделяющих их от хеш-меток.

Answer 3

Насколько я знаю, вы не можете git merge таким образом. Merge предназначен для объединения двух ветвей, имеющих общую историю, а не для сбора нескольких коммитов или серии патчей. Я чувствую, что сбор вишни - это то, что вы просите.

Вы можете использовать git cherry (не cherry-pick !), Чтобы узнать, какие коммиты должны быть вставлены в вашу ветку, затем git cherry-pick их. Вы также можете явно попросить git cherry-pick записать происхождение этих коммитов в случае, если вы выбираете вишню из публичной ветки. Это, вероятно, лучший способ справиться с этой проблемой. (Другой вариант - экспортировать их через git format-patch , а затем импортировать их с помощью git-am / git-apply, но это, вероятно, будет медленнее, плюс он не будет записывать происхождение коммитов .)

РЕДАКТИРОВАТЬ: «Public» (ветвь) следует понимать как нечто, не подлежащее редактированию истории. Конечно, вы можете сделать это при разработке программного обеспечения с закрытым исходным кодом без открытого кода.