Сохранять старые выпуски без создания долгоживущих веток

Question

Я новичок в Git.

Я прочитал: «Pro ​​Git: поддержание проекта» (книга) а также Git: Документация / howto / keep-git.txt

Сложный вопрос для меня: как сохранить старые версии без создания отдельных долгоживущих веток. Другими словами, мне интересно, как работать с веткой «maint» в проекте Git.

В примере (слияние с ветками тем и интеграция участников патчей не показаны, другие ветки "next", "pu" также здесь не показаны).

Эти изображения можно посмотреть также здесь .

          +--master
          |
          +--maint
          |
  (c1)->(c2)
          |
          +--tag : feature-release v1.0

В следующий раз:

tag:feature-rel v1.0--+                   +--master
                      |                   |
              (c1)->(c2)->(c)->(c)->(c)->(c)
                      |
                      +->(c)->(c)->(c)
                                    |
                                    +--maint
                                    |
                                    +--tag:maint-rel v1.0.1

Далее, как описано в "keep-git.txt", выполните:

 $ git checkout master
 $ git merge maint

Результат:

tag:feature-rel v1.0--+                          +--master
                      |                          |
              (c1)->(c2)->(c)->(c)->(c)->(c)->(c100)
                      |                       /
                      +->(c)->(c)->(c50)-----'
                                    |
                                    +--maint
                                    |
                                    +--tag:maint-rel v1.0.1

В следующий раз:

                               +--master
                               |
                               +--tag:feature-rel v2.0
                               |
   ...->(c)->(c100)->(c101)->(c102)
               /
 ...->(c50)---'
       |
       +--maint
       |
       +--tag:maint-rel v1.0.1

И на данный момент у меня есть несколько вопросов:

1. Что делать с веткой "maint"? Я так понимаю, указатель "maint" должен быть перемещен в ту же позицию, что и "master"? Как?
2. Потом как потом сделать ветку ветки "maint" из ветки "master"?
3. Если появиться патч (истечет очень долгое время, например, текущий выпуск функции v10.0) для старого «тега: maint-rel v1.0.1», как его интегрировать в «maint» и в "мастер"?

Спасибо.

Answer 1

как сохранить старые выпуски без создания отдельных долгоживущих веток

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

1 / Что делать с веткой "maint"? Я так понимаю, указатель "maint" должен быть перемещен в ту же позицию, что и "master"? Как?

Я не уверен, почему вы бы здесь повторно использовали maint. ребаз не сработает.
Может быть

$ git checkout maint
$ git reset --merge c102

Так как 'maint' уже был объединен с master, я думаю, этот сброс не обновит ни один из более новых файлов в master.

Я только что проверил:

альтернативный текст http://img188.imageshack.us/img188/4425/resetmerge.png

Он перемещает ГОЛОВКУ «maint», не затрагивая никаких файлов в master.

2 / Как потом сделать ветку ветки 'maint' из ветки 'master'?

Итак, сброс мог бы переместить головку 'maint' в текущую разработку: если C102 - это v2, все, что вам нужно, это проверить 'maint', и вы сразу же раскошелитесь.

Это даст вам:

альтернативный текст http://img36.imageshack.us/img36/91/resetmerge2.png

3 / если появятся патчи (истекшие очень долго, например, текущий выпуск функции v10.0) для старого «тега: maint-rel v1.0.1», как его интегрировать в «maint» а в "мастер"?

Там вам нужно создать "именованную ветвь обслуживания":

$ git checkout -b maint-1.0 c50
$ # work on patch
$ git checkout maint
$ git cherry-pick ... # only merge what you need in maint
$ git checkout master
$ git cherry-pick ... # only merge what you need in maint

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