Давайте нарисуем это.
У меня есть ветвь с именем release, которая разветвляется от мастера некоторое время назад.
A - B - C - F - G [master]
\
D - E [release]
Теперь сегодня, У меня есть две ветви, одна из которых основана на master, называемая basedMaster, а другая - на основе релиза, называемая basedRelease.
Я предполагаю, что вы добавили некоторые коммиты в эти ветви, в противном случае они не имеют значения .
H - I [basedMaster]
/
A - B - C - F - G [master]
\
D - E [release]
\
J - K [basedRelease]
Я недавно внес изменения в мастеринг при 10+ коммитах.
Давайте сделаем это два.
H - I [basedMaster]
/
A - B - C - F - G - L - M [master]
\
D - E [release]
\
J - K [basedRelease]
Итак, я получил другую ветку от basedMaster, называемую basedMasterLocal
[basedMasterLocal]
H - I [basedMaster]
/
A - B - C - F - G - L - M [master]
\
D - E [release]
\
J - K [basedRelease]
С этим у нас есть лучшее представление о состоянии хранилища.
Я хочу выяснить способ перебазирования этих 10+ коммитов в ветвь basedRelease.
Неясно, хотите ли вы, чтобы все коммиты были в master, но не в basedRelease, или только конкретно эти 10+ коммитов ты упомянул. И неясно, хотите ли вы скопировать их (cherry-pick) или переместить их (rebase).
У меня возникли проблемы, так как чтобы понять, как это сделать, поскольку я не хочу использовать cherry-pick и хотел бы решить эту проблему с помощью rebase.
В любом случае, вы можете выбрать вишню несколько коммитов. Это займет целый ряд коммитов. Мы можем использовать .., где x..y означает «все коммиты, которые достижимы от y, кроме тех, которые достижимы от x». См. gitrevisions / Specifying Ranges для получения дополнительной информации.
Предполагается, что вы basedRelease извлекли ... если вы хотите скопировать (cherry-pick) все коммиты в master, но не в basedRelease.
# All the commits reachable from master
# excluding those reachable from HEAD (the currently checked out commit).
git cherry-pick HEAD..master
Если это всего лишь 10+ коммитов, вы можете записать эти 10 коммитов. В этом примере это всего два, L и M.
git cherry-pick L M
Или вы можете заметить, что это коммиты, которые находятся в master, но не в basedMaster.
git cherry-pick basedMaster..master
И если вы хотите переместить (перебазировать) их.
git rebase --onto basedRelease basedMaster..master
Подобные примеры есть в примерах git -cherry-pick и git -rebase аналогичный пример в его описании .
Этот вид сложных обменов между долгоживущими ветвями является одной из причин, почему я рекомендую не иметь несколько долгоживущих ветвей, и определенно не иметь ветвей от них. Поддержание их в синхронизации c быстро усложняется.
Вместо этого я рекомендую иметь одну долгоживущую ветвь: master. Ничто не передается непосредственно master. Вся работа ведется на коротких тематических ветках. Они должны пройти QA до слияния в master. После объединения они удаляются. Таким образом, master всегда стабилен и готов к выпуску. Релизы отслеживаются с помощью тегов. Это рабочий процесс ветви .