Как добиться частной ветки в git, которая "плавает" при слиянии с апстримом?

Question

У меня есть форк репозитория другой организации. Я на последнем теге в репо, который не является головным, и я создал ветку из этого тега, которая никогда не будет вытеснена вверх по течению. Вот почему я считаю филиал частным.

Я сделал коммиты в свою частную ветку и использую этот код в своей производственной среде. Когда в верхний репозиторий добавлен новый тег, я хочу иметь возможность вытащить их изменения.

Однако я хотел бы всегда хранить свои коммиты в аккуратном стеке поверх их последнего тега. Тогда я не хочу объединяться, так как мои коммиты в конечном итоге будут жить далеко в истории, и я хочу видеть их прямо сверху, чтобы я мог легко работать с ними, когда я использую определенные инструменты в своем хранилище.

На самом деле, я хочу "плавающую" ветку, которую я могу перенести в произвольную точку, когда внесу изменения в верхний поток в мой репозиторий.

[правит] Однако я не верю, что могу использовать re base, поскольку это операция перезаписи истории. Видите ли, я использую свой репозиторий на двух машинах, моя разработка и производство. Я делаю свои коммиты на машине разработки, нажимаю на github, а затем работаю. Все это не имеет ничего общего с изменениями в вышестоящем репозитории, из которого я изначально разветвился.

Я не совсем уверен в пересадке, сборе вишни или другом подходящем инструменте. Какой бы инструмент это ни был, я понимаю, он не должен переписывать историю. Из моего прочтения я вижу, что переписывание истории репо - нет-нет при нажатии. Поэтому я не уверен, какие команды я должен использовать, чтобы пересадить ветку без переписывания истории.

Если бы я использовал Mercurial, я мог бы рассмотреть что-то вроде MQ с управлением версиями. Я не знаю аналогичного решения для git, если он есть или есть другой, более подходящий инструмент для git.

[редактировать]

После оценки ответов, которые я получил здесь, я наконец определил, что сбор вишни был правильным ответом. Во всех случаях re base удаляет историю, и, поскольку это общий репозиторий, удаление истории недопустимо, по крайней мере, для каждого источника, который я прочитал.

Однако Cherry-picking копирует коммит в мое рабочее дерево, не удаляя его из исходного местоположения. Так что я могу поместить копию своих изменений поверх последней метки и поместить их в аккуратную кучу.

Для справки, я также попытался сделать это с Mercurial, используя расширение hg-git, которое позволяет вам использовать hg для клонирования репозитория git. В этом были свои плюсы и минусы. Самым большим минусом было то, что когда я закончил использовать его, он не мог толкать. hg-git работает счастливо до этого момента, а затем говорит вам, что не работает с hg 1.9. Поддельные, если не сказать больше. Другим минусом было то, что клонирование и извлечение большого набора изменений происходит крайне медленно. Тем не менее, инструменты разрешения конфликтов слияния mq и TortoiseHg - это значительное улучшение по сравнению с git cherry-pick и Smartgit. Я бы хотел, чтобы hg-git работал.

Я полагаю, что в конце концов "плавание" не было таким хорошим описанием для моей ветки изменений, так как в результате ее нужно скопировать, а не переместить. Извините за мое, возможно, плохое описание, я все еще выяснял, какие именно варианты. Спасибо за помощь.

Answer 1

git fetch
git rebase --onto latesttag previoustag yourbranch

Конфликты должны быть разрешены и полностью зависеть от того, что вы делаете с файлами, которые могли измениться с одного тега на другой. В частности, если кто-то удалил какой-то код, который вы изменяете, вам придется решить эту проблему и убедиться, что код, который вы изменили, теперь может быть применен в другом месте. Для этого нет серебряной пули. Как только вы решили свои конфликты, и все работает,

git add -A
git rebase --continue

Промыть, повторить.

Чтобы добавить, если вы делаете это, чтобы просто иметь возможность развертывания, "плавающая ветвь" может быть не лучшим методом для решения этой проблемы. Рассмотрим эти альтернативы:

1. сценарии развертывания, которые управляют файлами, чтобы гарантировать, что развертывание работает.
2. Смазать / очистить скрипты, которые изменяют файлы при заполнении рабочего каталога. ( https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes)

Ваша плавающая ветка кажется, что она существует только ради вашей собственной среды и, следовательно, не должна быть частью проекта.

Answer 2

Вы описываете работу git rebase --onto Вот.

Сценарий:

• git fetch с пульта;
• в целях безопасности создайте новую копию: git branch newbranch currentbranch;
• скажем, старый тег, на котором вы сейчас основываетесь, oldtagи новый тег newtag;
• "Трансплантат": git rebase --onto newtag oldtag newbranch;
• разрешать конфликты, если это необходимо;
• git branch -D currentbranch;
• git branch -m newbranch currentbranch,

Однако, что касается переписывания истории, вы - из вашей ветви, а не из исходного репозитория, у вас нет доступа для записи в нее, не так ли?