tl; dr: вероятно, лучше использовать git rebase -i
Не думаю, что вижу, что вы ожидаете получить от тегов.Чтобы не произносить
git cherry-pick commit
для каждого коммита, вместо этого вы должны сказать
git tag my_tag commit
и , тогда все равно придется запустить скрипт для копирования коммитов ...это больше, чем просто делать это вручную.(Кроме того, приведенные выше команды тегов не будут работать так, как вы хотите, потому что данный тег указывает на ровно один объект; поэтому вам придется использовать много тегов, и ваш скрипт cherry-pick найдет всеиз них ...)
Нельзя сказать, что ручной сбор вишни - лучший способ.Смысл «выбора вишни» заключается в том, чтобы получить «одно изменение, которое мне нужно»;если вам нужно обработать всю ветку, возможно, проще использовать git rebase.Операция rebase часто неправильно понимается;он копирует коммиты, очень как вишня(Люди часто думают, что он «заменяет» коммиты, удаляя оригиналы; это не совсем так. Это может изменить историю реферирования, но это все.)
Так, например,если вы начнете с
A -- B -- C -- D -- E -- F -- G -- H <--(main-branch)
, вы можете
git checkout main-branch
git checkout -b release-branch
git rebase -i master~6
(я использовал master~6, потому что это выражение ссылается на идентификатор объекта B; B(хэш) также будет работать. Я выбрал B, потому что C - это первый коммит, который вы не хотите сохранять - поэтому перезапись начинается после B. Если вы хотите удалить A, вы можете использовать выражениекоторый разрешает родительский элемент A, если A имеет родителя, или использует --root, если A не имеет родителя.)
Теперь git откроет редактор и покажет вам "список задач, с одной строкой для каждого коммита в вашей ветке обратно (но не включая) B.Для коммитов, которые вы хотите удалить, измените первое слово в строке этого коммита с pick на drop (или просто удалите строку).
Когда вы выйдете из редактора, начнется операция rebase "копирование "коммитов (т.е. создание новых коммитов, которые применяют те же изменения на новой базе).На каждом шаге могут быть конфликты (если изменение в более позднем коммите зависит от изменения в более раннем коммите, который вы удалили);Вам будет предложено разрешить их и продолжить операцию ребазирования.
Когда это будет сделано, у вас будет
A -- B -- C -- D -- E -- F -- G -- H <--(main-branch)
\
D' -- F' -- G' <--(release-branch)
, где D' применяет те же изменения, что и D и т. д.
Это не лишено потенциальных недостатков (хотя недостатки для rebase такие же, как и для cherry-pick);это действительно зависит от того, что вы будете делать с ветками отсюда.Если release-branch это просто состояние терминала, которое вы отпустите и забудете, то, вероятно, все в порядке.Если вам может понадобиться исправить релиз, вы обнаружите, что объединение между release-branch и main-branch может быть затруднено;тогда вам, возможно, придется использовать cherry-pick или rebase, чтобы поделиться исправлением между выпуском и основной линией разработки.