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

14
branch git git-branch merge version-control

3 ответов

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

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

0

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

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

rebase --onto release B bug

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

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

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

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

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

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

9

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

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

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