Как слить ветку освобождения назад освоить

Question

У нас есть две основные ветви:

• master Обновлены разработчиками
• release Обновленные ХИ. Разработчики не нажимают на эту ветку.

Нашей автоматизированная непрерывная интеграция как это работает:

1. CI принимает самую последнюю версию филиала выпуска
2. строит систему
3. интегрирует последний код от главного отделения (без толчка)
4. выполняет все тесты
5. , если все тесты хороши: номер версии обновляется, и филиал выпуска обновляется.

Это есть одна проблема:

Номер версии в мастер не получает приращение.

Если бы мы делали это, был бы бесконечный цикл, так как CI думает:

ах, новые изменения на мастере (он не видит, что это только обновление номера версии). Давайте проверим код ....

Как получить изменения от CI назад к мастеру?

Мы хотим избежать слияния, когда все CI совершают попадание в мастера. На часто обновляемых репозиториях ежедневно будет CI. Результатом будет то, что в истории git слишком много CI-коммитов. С «слишком многими» я имею в виду «слишком много» для человеческого глаза.

Update

Мы делаем "непрерывной интеграции". Дважды в день программное обеспечение тестируется. Если он стабилен, номер версии увеличивается. В нашем контексте нет «дня выпуска».

У нас есть ветви развития/особенности. Но я думаю, что это не вопрос. Слияние с мастером осуществляется разработчиком. Это не автоматизировано.

Answer 1

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

Использование другой ветки для реализации CI является ИМХО запутанным способом, который принесет вам только сложности и проблемы (например, этот вопрос).

Если действительно вы хотите использовать release ветвь для выпуска вы должны никогда слепо влить в него изменения от master. И вы должны никогда не сливать его обратно в master либо с master, а теперь развивается в следующий выпуск. - контекст двух ветвей расходится, только потому, что изменение работает в одной ветви, не означает, что он будет работать в другом.

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

Answer 2

Ну ... как насчет стратегий переключения?

Работайте в ветвях разработки, объединитесь в мастера, ci выпускает мастер (или теги, если хотите).

Для git мастер является официальной историей проекта, ветви существуют только для того, чтобы внести вклад в мастера.

В настоящее время я знаю два (нормально три с linux) различных основных процедур, работающих с git. Первый - github model, другой - Gitflow. Gitflow немного сложнее, а также часто не требуется.

Зачем изобретать пользовательскую стратегию, если уже существует два существующих рабочих решения?