У меня есть форк репозитория другой организации.Я на последнем теге в репо, который не является головным, и я создал ветку из этого тега, которая никогда не будет вытеснена вверх по течению.Вот почему я считаю ветку частной.
Я сделал коммиты в свою частную ветку и использую этот код в своей производственной среде.Когда новый тег создается в вышестоящем репозитории, я хочу иметь возможность извлекать их изменения.
Однако я бы хотел всегда хранить свои коммиты в аккуратном стеке поверх их последнего тега.Тогда я не хочу сливаться, так как мои коммиты в конечном итоге будут жить далеко в истории, и я хочу видеть их прямо сверху, чтобы я мог легко работать с ними, когда я использую определенные инструменты в своем хранилище.
Так что на самом деле я хочу «плавающую» ветку, которую я могу переместить в произвольную точку, когда внесу изменения в исходный поток в свой репозиторий.
[правит] Я не верю, что могу использовать rebaseоднако, поскольку это операция перезаписи истории.Видите ли, я использую свой репозиторий на двух машинах, моя разработка и производство.Я делаю коммиты на машине для разработки, нажимаю на github, а затем работаю.Все это не имеет ничего общего с изменениями в вышестоящем репозитории, из которого я изначально разветвлен.
Я не совсем уверен в пересадке, сборке вишни или любом другом подходящем инструменте.Какой бы инструмент это ни был, я понимаю, он не должен переписывать историю.Из моего чтения я вижу, что переписывание истории репо - нет-нет при нажатии.Поэтому я не уверен, какие команды, которые я должен использовать, будут трансплантировать ветку без переписывания истории.
Если бы я использовал Mercurial, я мог бы рассмотреть что-то вроде mq с управлением версиями.Я не знаю аналогичного решения для git, если он есть или есть другой, более подходящий инструмент для git.
[edit]
После оценки полученных ответовздесь я окончательно определил, что сбор вишни был правильным ответом.Во всех случаях rebase удаляет историю, и, поскольку это общий репозиторий, удаление истории недопустимо, по крайней мере, для каждого источника, который я прочитал.
Cherry-picking, однако, копирует коммит в мою работудерево, не удаляя его из своего первоначального местоположения.Поэтому я могу выложить копию своих изменений поверх последней метки и поместить их в красивую аккуратную кучу.
Для справки, я также попытался сделать это с Mercurial, используя расширение hg-gitкоторый позволяет использовать hg для клонирования репозитория git.В этом были свои плюсы и минусы.Самым большим минусом было то, что когда я закончил использовать его, он не мог нажать.hg-git работает счастливо до этого момента, а затем говорит, что не работает с hg 1.9.Поддельные, если не сказать больше.Другим минусом было то, что клонирование и извлечение большого набора изменений происходит крайне медленно.Тем не менее, инструменты разрешения конфликтов слияния mq и TortoiseHg - это значительное улучшение по сравнению с git cherry-pick и Smartgit.Хотелось бы, чтобы hg-git мог сработать.
Полагаю, что в конце концов "плавающее" не было таким хорошим описанием для моей ветви изменений, поскольку в результате мы копируем ее, а не перемещаем.Извините за мое, возможно, плохое описание, я все еще выяснял, какие именно варианты.Спасибо за помощь.