Сообщение Re[2]: Слияние release-ветки от 11.12.2015 11:22
Изменено 11.12.2015 11:30 tdiff
Здравствуйте, netch80, Вы писали:
N>Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт?
N>Или вы релизами назвали feature-ветки?
Нет, под релизом я имел в виду имеено ветку из которой собираются бинарники в конце концов. В нашем случае такая ветка за неделю набирает ~50 коммитов. В то же время в devel идёт разработка будущих фичей.
N>Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
N>Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт?
N>Или вы релизами назвали feature-ветки?
Нет, под релизом я имел в виду имеено ветку из которой собираются бинарники в конце концов. В нашем случае такая ветка за неделю набирает ~50 коммитов. В то же время в devel идёт разработка будущих фичей.
N>Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
Re[2]: Слияние release-ветки
Здравствуйте, netch80, Вы писали:
N>Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт?
N>Или вы релизами назвали feature-ветки?
Нет, под релизом я имел в виду имеено ветку из которой собираются бинарники в конце концов. В нашем случае такая ветка за неделю набирает ~50 коммитов. В то же время в devel идёт разработка будущих фичей.
N>Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
Но, наверно, лучший подход зависит от степени "сложности" коммитов в релизной ветке. Если они нетривиальные, то, может быть, лучше их вмёржить один раз, а не генерировать дупликаты коммитов.
N>Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт?
N>Или вы релизами назвали feature-ветки?
Нет, под релизом я имел в виду имеено ветку из которой собираются бинарники в конце концов. В нашем случае такая ветка за неделю набирает ~50 коммитов. В то же время в devel идёт разработка будущих фичей.
N>Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
Но, наверно, лучший подход зависит от степени "сложности" коммитов в релизной ветке. Если они нетривиальные, то, может быть, лучше их вмёржить один раз, а не генерировать дупликаты коммитов.