Вишневый сбор против ребазинга - PullRequest
Новая
       51

Вишневый сбор против ребазинга

3 голосов
/ 11 июня 2010

Вот сценарий, с которым я обычно сталкиваюсь:

У вас есть набор коммитов на master или design, которые я хочу поместить поверх production ветви.

Я стремлюсь создать новую ветвь с основанием, как production Вишни, выберите эти коммиты и объедините ее с production

Затем, когда я сливаю master в производство, я сталкиваюсь с конфликтами слияния, потому что даже если изменения одинаковы, но они зарегистрированы как другой коммит из-за cherry-pick.

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

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

Должен ли я использовать ребазинг там, где я черпаю. Какие еще преимущества это имеет над этим?

1 Ответ

4 голосов
/ 11 июня 2010

Вы должны сделать rebase --interactive свою ветку дизайна поверх производства, где:

  • вы можете изменить порядок ваших коммитов, начиная с тех, которые вам нужны в производстве
  • затем вы можете объединить производство с последним коммитом дизайна, который вы хотите включить (ускоренная перемотка вперед) 
    -x--x--x1--x--x2 (design)
      \
       p--p (production)

С x1 и x2, которые необходимо включить в производство: 

git checkout design
git rebase --interactive production

-x
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (design)

Тогда: 

git checkout production
git merge x2'
-x
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (design)

Это позволяет вам:

  • для проверки текущих проектных коммитов против производственных коммитов (во время перебазирования)
  • изменить порядок коммитов
  • включить первые в производство
  • позволяет быстро переходить от дизайна к производству.

Лакшман Прасад добавляет:

Большую часть времени я нажимаю на изменения в конце дня. Так что не очень помогает. Как изменится ваш ответ для заданной главной ветви

Я бы сделал то же самое, но с частной веткой, созданной только для операции: 

git checkout master
git checkout -b master-private

    -x--x--x1--x--x2 (master, master-private)
      \
       p--p (production)

, затем ребаз, на этот раз с частной веткой (то есть веткой, которую вы никогда не продвинете). 

git rebase --interactive production

-x--x--x1--x--x2 (master)
  \
   p--p (production)
       \ 
        x1'-x2'--x'--x' (master-private)

Тогда: 

git checkout production
git merge x2'

-x--x--x1--x--x2 (master)
  \
   p--p--x1'--x2' (production)
                \
                 x'--x' (master-private)

master не получит выгоды от переупорядочения фиксации (с более логичным порядком), но, по крайней мере, вы можете нажать master, когда захотите.

И production все еще может включать в себя именно то, что ему нужно.
Если последующие коммиты на master имеют ту же проблему (некоторые должны быть включены в production, другие будут позже), я бы:

  • удалить master-private (нас это не волнует, копия х фиксирует от мастера)
  • сделать ветку master-private поверх мастера
  • заново выполните rebase --interactive, используя грубую тактику разрешения конфликтов (за исключением первых коммитов в этой ветке master-private, поскольку те должны быть интегрированы в ветку production) 
    -x--x--x1--x--x2--x--x3--x (master)
      \
       p--p--x1'--x2'--x3' (production)
                   |     \
                   |      x''--x'' (master-private)
                    \
                     x'..x' (old x' from the first master-private)
...