Git - upstream + функциональные ветки + релизные ветки

Question

Я использовал рабочий процесс перебазирования веток темы http://www.golden -gryphon.com / software / misc / packaging.html

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

Единственное, что приемлемо, это объединение рабочих процессов. Теперь проблема в том, что я не знаю, как работать с зависимыми ветвями функций в этом рабочем процессе. При перебазировании это было просто: с каждым патчем я просто перебрасывал все ветви функций, которые зависели от этой ветки, и все возвращалось в норму. С рабочим процессом слияния я не могу перебазировать свои ветви функций, но слияние кажется немного безумным для этого.

Есть ли какой-нибудь лучший подход?

Answer 1

При наличии нескольких долгосрочных функций модель может выглядеть следующим образом:

     o-----o  bugfix
    /       \
o--o--o------o------o  develop branch
       \      \      \
        o-o----o---o--o  long-term feature 1
           \    \   \  \
            o--o-o-o-o--o--o feature 2

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

Точно так же у вас есть ветка функций для reature 2, основанная на функции 1, и вы обновляете еепутем слияния нового материала новая ветвь функции 1.

Когда функция 1 завершена, вы объединяете ее обратно для разработки и обновляете функцию 2 из ветви разработки:

     o-----o  bugfix
    /       \
o--o--o------o------o---o---o  develop branch w/ feature 1
       \      \      \ /     \
        o-o----o---o--o       \
           \    \   \  \       \
            o--o-o-o-o--o--o--o-o feature 2

Answer 2

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

Типичный рабочий процесс слияния выглядит так:

             o-o-o--------------o         Release1+bugfixes
            /     \              \
o-----o----o--o-o--o---o----o-o-o-o-o--o  develop
       \     /               \     /
        o-o-o Feature 1       o---o Feature 2

Краткосрочные функции разрабатываются в разработке, долгосрочные функции приобретают свои ветви. Функциональные ветви возвращаются в разработку. Для каждого релиза создается ветка от разработки, и исправления создаются в ветке релиза, где появилась ошибка. Когда исправление устранено, оно возвращается в разработку.

Лучшее объяснение можно найти на http://nvie.com/posts/a-successful-git-branching-model/.