Как управлять ветвями выпуска

Question

Мы пытаемся управлять несколькими ветвями выпуска с помощью git. Наша отраслевая организация типична. Первичное постоянное развитие находится на хозяине. Разделы темы используются для работы и объединены в master. Мастер - следующий крупный релиз. Однако мы также работаем над промежуточными релизами (точечные версии). Например, мастер будет работать в направлении версии 7.4, пока мы также работаем над 7.3.2.

Естественно, что большинство (всех?) Выполненных работ для 7.3.2 должно быть в 7.4. Это больше всего, работы, выполненной для ветви релиза 7.3.2, также должны быть выполнены для ветви релиза мастера (т.е. 7,4).

Какие методы вы используете для управления этими ветвями? В частности, обеспечение того, чтобы изменения были объединены в обе ветви?

Наше решение заключалось в создании параллельных ветвей темы. Как только тема была завершена на той или другой ветви релиза, она копируется в другую ветку темы из другой ветви релиза, используя cherry-pick или rebase --onto, а иногда даже ручную разницу и слияние.

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

Спасибо за ваши предложения

Answer 1

мы используем этот рабочий процесс ветвления в-функции:

https://plus.google.com/109096274754593704906/posts/R4qkeyRadLR

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

Answer 2

Это зависит от того, сколько вы ожидаете, но у нас есть наши репозитории Git, подключенные к Trac и билетной системе там. Мы написали некоторые пользовательские перехватчики для Git (которые я могу предоставить вам, если хотите), которые заставляют сообщения совершать сообщения в определенном формате, включая цитирование билетов. Trac обрабатывает все остальное, отправляя сообщения о фиксации на билеты. Ссылка на билет не указана. Так что абсолютно все должно иметь билет, связанный с ним.

У нас также есть изменения в билете, отправленные по электронной почте нескольким людям. Если наступает толчок и идет только по одной ветке, когда он должен идти на других, один из контролеров билетов (которые являются старшими разработчиками с OCD) отправляется и снова открывает/пристает к человеку, который сделал толчок, пока он не появится на всех соответствующие ветви.

Механика того, как коммиты заканчиваются на разных ветвях, зависит от разработчика. Некоторые, как вишневый выбор, другие перегружают, другие патчи. Меня не волнует, как он добирается до тех пор, пока все ветви, которые нуждаются в фиксации, получат это!