Я использую ветку master для разработки и release для выпуска связанных материалов. В идеале я хотел бы, чтобы они выглядеть перед каждым выпуском:Как обновить ветвь релиза?
v release
o - o - o
/
o - o - o - o
^master
Это может быть достигнуто за счет перебазирования релиз на master, однако затем толкая release к зарождению становится проблематичным. Как лучше всего справиться с этим?
Обычный способ справиться с этой ситуацией была бы заставить подтолкнуть release ветви пульта, с помощью:
git checkout release
git push --force origin release
Как вы, наверное, подозреваете, это становится проблематичным, поскольку она переписывает историю общественного release филиала , что означает, что любой, кто затем тянет эту ветку, может получить неожиданные результаты.
Однако, давайте подробнее рассмотрим значение ветви release. Как правило, появилась ветвь релиза, потому что для важного компонента вашего программного продукта требуется множество функций. После завершения выпуска соответствующая ветвь может быть заморожена и далее заблокирована. Если исправления необходимы для выпуска, дайте им перейти в новую ветку.
Чтобы добраться до кульминационного пункта, вы бы достаточно безопасными в перебазировании в release ветви на master и силу нажатия, если несколько людей, или даже не один, нужно вытащить эту отрасль снова. И этот момент времени будет именно тогда, когда релиз погаснет, и в этот момент все действия на вашем release филиале должны прекратиться.
Таким образом, мой совет будет заключаться в том, чтобы надавить на вашу ветку release в конце цикла.
использование merge вместо rebase
Золотое правило мерзавца перебазироваться, чтобы никогда не использовать его на общественных ветвей
Как fireflieslive упоминалось, вы должны использовать сливать вместо перебазироваться. Таким образом, ваша история будет выглядеть следующим образом:
v release(1) v release(2)
o - o - o ------- o - o - o
/ /
o - o - o - o - o - o - o - o - o
^master(1) ^master(2)
где я теперь изображены две различные версии (и статус мастера в момент этого выпуска).
В частности, каждый раз, когда вы хотите, чтобы освободить вас
git checkout release
git merge master
<edit release related stuff and commit>
Я удалил ПРИНЯТИЕ и дал +1 вместо этого, так как я чувствую теперь, что это не идеальное решение, и после использования rebases я лично решил использовать сливает вместо этого. В основном потому, что я также отмечаю каждую фиксацию, которую я построил, а затем история начинает выглядеть очень неестественно. – Dunno
@Dunno Фактически слияние делает историю неестественной, потому что она ее стирает. Восстановление базы сохраняет историю, потому что она поддерживает сделанные коммиты. Но выбор за вами. –
Я знаю, я, вероятно, в конечном итоге использую смесь обоих ... – Dunno