Git: объединить только изменения, сделанные на ветке - PullRequest
Новая
       54

Git: объединить только изменения, сделанные на ветке

19 голосов
/ 06 июля 2011 
  G---H             // Release Branch
 /
/
A---B---E---F---    // master
    \
     \
      C---D---     // bug fix branch

Исходя из наших особых потребностей в нашем проекте, вполне вероятно, что приведенный выше сценарий имеет место.У нас есть ветка master / dev с некоторыми коммитами.Затем мы получаем отчет об ошибке и начинаем исправлять это в ветке ошибок (фиксирует C и D выше).Тем временем в ветке разработчика происходит больше коммитов.Далее нам говорят, что нам нужно создать релиз для клиента, который не может включать изменения, внесенные вышеупомянутыми коммитами B, E и F, но он должен включать исправление ошибки.

Таким образом, мы разветвляемся от dev перед изменениемБ когда-либо применялся, но как лучше всего исправить ошибку в этой ветке релиза?Если я выполню слияние ветки, оно будет включать изменения, которые были сделаны в B, которые я не хочу.Я мог бы выполнить вишневый коммит коммитов C и D, но я читал, что вишневый сбор не всегда является хорошей идеей на основе этого ответа , в основном потому, что мой репо будет выглядеть так: 

  G---H---C'---D'--- // Release Branch
 /
/
A---B---E---F---     // master
    \
     \
      C---D---       // bug fix branch

Таким образом, C 'и D' появляются как совершенно новые коммиты с разными идентификаторами sha-1, как C и D. Это действительно плохо?К каким проблемам это может привести?Есть ли лучший способ получить изменения из ветки исправления ошибок в ветке релиза?

Ответы [ 3 ]

10 голосов
/ 06 июля 2011

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

Но вместо того, чтобы собирать вишню, вы можете подумать о том, чтобы просто перебить ветку: 

rebase --onto release B bug

, где release - ветвь релиза, а bug - ветвь ошибки.

Затем вы получите что-то вроде 

         C'---D' //Bug branch      
        /
       /
  G---H  // Release Branch
 /    
/ 
A---B---E---F---     // master

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

Вам решать, что лучше для вас работает.

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

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

Нет реальной опасности в использовании cherry-pick, особенно если вы не планируете когда-либо сливать ветку release в master.

В общем, вы можете предотвратить подобные проблемы с помощьюОсновывая исправления ошибок на коммитах, которые включены во все ветви, в которые вы хотите объединить исправление.При разработке самого git это достигается путем объединения всех исправлений ошибок в ветку maint (т. Е. Текущей стабильной серии, которая получает только исправления), а затем периодически объединяет ее в master.Таким образом, исправление повсюду и слияния нормальны.

2 голосов
/ 19 ноября 2012

Примечание: как объяснено выше, сбор вишни здесь допустим.
Его основные недостатки:

В вашем случае:

  • нет необходимости объединять обратно.
  • , если вы уверены, что C и D не основаны на коде, введенном в B, ... черри выбирай их там, где они тебе нужны.
...