Измените корень ветки в git

Я использую git и хочу изменить базу выходящей ветки. Это вызвано системой развертывания, которая вытаскивает эту явную ветвь в мою производственную среду. При планировании релизов я создаю тег каждый раз, когда хочу жить. Но моя ветвь также имеет специальные изменения, поэтому git reset --hard v1.0 не будет работать.

Вот небольшой пример. Я хочу это

      C---D---E deploy
     /
A---B---F---G master
     \
      v1.0

чтобы стать этим

                          C---D---E deploy
                         /
A---B---F---G---H---I---J---K master
     \                   \
      v1.0                v1.1

Может быть, git rebase - это то, что я ищу, но страницы с людьми не помогают мне. Спасибо за ваши ответы!

Ответы

Ответ 1

git rebase должен, как вы говорите, позволить вам изменить базу развертывания:

git checkout deploy
git rebase v1.1 # using the tag
(or:
 git rebase J # SHA1 of J
 or
 git rebase master~1
)

Но вы получите

C'---D'---E' deploy

То есть, SHA1 коммандной части ветки deploy переписывается, что не так уж плохо, если никто не клонировал ветку deploy и не работал над ней.
Поскольку это ветвь для развертывания, это, скорее всего, имеет место (т.е. Никто не работал над клоном упомянутой ветки).

Ответ 2

Я не понимаю, почему вы хотите потерять свою оригинальную ветку. Что бы я сделал в таком случае:

 # create a new branch from your 1.1 tag
 git checkout -b deploy1.1 v1.1 
 # merge your existing branch into this one
 git merge deploy

EDIT: добавлена схема

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

       C---D---E deploy
       /        \_______ 
      /                  F deploy1.1
     /                  /
A---B---F---G--H--I--J--K--L
     \                   \
    v1.0                 V1.1

Ответ 3

git rebase должен работать для вас:

git checkout deploy
git rebase master~1

или

git rebase v1.1

Взгляните на http://progit.org/book/ch3-6.html - вам следует лучше понять, как лучше передумать

Ответ 4

да, вы можете использовать rebase для достижения желаемого эффекта. следующая команда проверяет ветвь deploy и воспроизводит все ее коммиты, недоступные через v1.1, поверх v1.1:

git rebase v1.1 deploy

(верным будет: git rebase --onto v1.1 v1.0 deploy)

но зачем восстанавливать и изменять историю? вы можете просто изменить основную линию разработки в свою ветку развертывания:

git checkout deploy
git merge v1.1

это оставит все ваши хеши фиксации неповрежденными, тогда ваша история будет выглядеть так (M является фиксацией слияния):

      C---D---E-----------M deploy
     /                   /
A---B---F---G---H---I---J---K master
     \                   \
      v1.0                v1.1

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