Как перемещать исправления между ветками в DVCS? - PullRequest
8 голосов
/ 15 июля 2011

Если мы обнаружим ошибку в какой-то ветке, мы исправим ее (отметьте Новый релиз на картинке).Но нам также интересно перенести это исправление в Старый выпуск и Основная ветка разработки:

a-->b-->c              (Old release)
|    
A-->B-->C-->D           (Main release)
    |
    1-->2-->bugfix-->4  (New release)

svn запомнить в свойствах svn: merge(от svn 1.6, 2009), какая редакция слилась с какими филиалами.Поэтому в следующий раз, если вы объединяете регион ревизий, ранее слитые ревизии были пропущены из патча слияния.

Как работать с современным DVCS?

Мне нужно сделать простой патч и применить его к каждой ветви, или естьсуществует какая-то помощь от DVCS?

Примечание : я не могу просто объединить Новый филиал Основной , так как предыдущие наборы изменений также перемещаются в Main branche.

Перебазирование также невозможно, так как Новый релиз поступает ко многим разработчикам.

Я заинтересован в ответе для именованной схемы Braches и для схемы с несколькими репозиториями.

PS. Энди предлагает найти общего родителя для всех веток, для которых ошибка затронула, обновить его, применить исправление к ошибке и переместить исправление к затронутым ветвям.

Обновляя старый набор изменений и внося изменения, вы создаете новую ветку.Я рекомендую создать именованную ветку (назовите ее bugID ), чтобы позже вы могли легко вернуться к ней.

Есть проблема с поиском общего родителя для всех ветвей, в которых мы заинтересованы исправитьошибка.

Первое решение (которое предлагает Andy ) использует $ hg / git / bzr blame и тщательно проверяет вывод для всех затронутых файлов.Это включает в себя первую ошибку исправления некоторых новейших наборов изменений, прежде чем вы обнаружите с помощью blame , какие наборы изменений представляют ошибку.Затем вам нужно rebase fix (patch) для общего родительского набора изменений.

Другое решение использует $ hg / git / bzr bisect (вы также можете вручную выполнить обновления длянайти первую ревизию, в которой введена ошибка).Это может быть обширным, но более подходящим решением true , так как позволяет заполнить исправление до любых веток, в которых присутствует ошибка.

Я думаю, что лучше сначала найти сначала BAD изменить набор и затем исправить ошибку, вместо того, чтобы сначала исправить ошибку, а затем найти первый BAD набор изменений (кроме случая, когда вы уже знаете, как исправить ошибку).Также наличие diff, которое вводит, может помочь понять, почему это происходит.

PPS. С ошибками ясно, какая ветвь была произведена, чтобы разрешить изменения слияния для любой затронутой ветви.

Интересный вопрос возникает, если спросить, как функция backport от ветки разработки до ветки релиза.Как вы можете видеть, вы должны фиксировать наборы изменений, начиная с набора изменений до выпуска ветки.Но когда вы разрабатываете функцию, вы не можете знать, где вам нужна функция обратного порта.С svn: merge VCS запомните для вас все backports.Как насчет DVCS?

Ответы [ 3 ]

8 голосов
/ 15 июля 2011

Вы могли бы:

  1. Найти общего родителя. Спасибо Новелократу за этот шаг.
    git merge-base branch1 branch2 branch3 ...

  2. Оформить заказ на общего родителя
    git checkout A

  3. создать новую ветку для исправления ошибок в
    git checkout -b bugFix

  4. Исправлять ошибки и фиксировать их в ветке исправлений ошибок

  5. Ветка проверки, которая нуждается в исправлении ошибки
    git checkout branchToApplyFixTo

  6. Слить исправление ошибки в ветку
    git merge bugFix

3 голосов
/ 15 июля 2011

Вы можете git cherry-pick bugfix на каждой затронутой ветви, которую вы хотите исправить. Это создаст новый идентификатор фиксации для исправления в каждой ветви.

2 голосов
/ 15 июля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...