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

3 ответов


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

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


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

но вместо выборочного, вы могли бы рассмотреть просто перебазирования филиала:

rebase --onto release B bug

здесь release является ветвью выпуска и bug - это отрасль ошибок.

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

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

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

это до вас, чтобы решить, что лучше работает для вас.

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


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

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

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