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

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

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

Итак, мы отключаем dev до того, как изменилось приложение B, но каков наилучший способ исправить ошибку в этой ветке релиза? Если я выполняю слияние ветки, это будет включать изменение, которое было сделано в 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. Это действительно плохо? С какими проблемами это может привести? Есть ли лучший способ получить изменения от ветки исправления ошибок в ветки релиза?

Ответ 1

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

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

Ответ 2

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

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

rebase --onto release B bug

где release - ветвь освобождения, а bug - ветвь ошибки.

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

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

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

Вам решать, что лучше всего подходит вам.

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

Ответ 3

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

в случае слияния, вы столкнетесь с конфликтом из-за повторяющихся коммитов
См. "Git целостность вишни и целостность данных > "
игнорировать функциональные зависимости.
См. "Как слить конкретную фиксацию в git".

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

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