Многим известно, что есть такой workflow, когда в определённый момент создаются т.н. "релизные" ветки, в них пушатся коммиты и в конце-концов всё это заканчивается релизом.
При этом полагается эту ветку затем влить в "develop" ветку.
У меня вопрос, как у вас организуется это слияние, если за время существования релизной ветки:
1. в релизную ветку пушится много коммитов большим числом людей;
2. в девел ветку пушится много коммитов таким же числом людей;
3. при попытке влить релизную в девел происходит большое число конфликтов, чтобы разрезолвить которые требуется так же большое число людей.
?
Здравствуйте, tdiff, Вы писали:
T>Многим известно, что есть такой workflow, когда в определённый момент создаются т.н. "релизные" ветки, в них пушатся коммиты и в конце-концов всё это заканчивается релизом.
Неверно. "Релизная ветка" создаётся наоборот — для ограждения от изменений! Делается ветвь, которая замораживается для внесения фич и принимает только багфиксы. В день релиза собирается бинарь и публикуется, ветка "забывается".
Когда находят критические изменения, "забытый релиз" тоже обновляется (по желанию).
T>3. при попытке влить релизную в девел происходит большое число конфликтов
Обычный бардак в команде. Разберитесь с ответственными за модули программы и не пилите всё хором.
Здравствуйте, Kolesiki, Вы писали:
K> T>Многим известно, что есть такой workflow, когда в определённый момент создаются т.н. "релизные" ветки, в них пушатся коммиты и в конце-концов всё это заканчивается релизом. K> Неверно. "Релизная ветка" создаётся наоборот — для ограждения от изменений! Делается ветвь, которая замораживается для внесения фич и принимает только багфиксы.
Можно добавить, что все запушенные в релизную ветку изменения желательно тут же мержить в девелоперскую ветку.
T>У меня вопрос, как у вас организуется это слияние, если за время существования релизной ветки: T>1. в релизную ветку пушится много коммитов большим числом людей; T>2. в девел ветку пушится много коммитов таким же числом людей; T>3. при попытке влить релизную в девел происходит большое число конфликтов, чтобы разрезолвить которые требуется так же большое число людей. T>?
Больше похоже, что это не релизная ветка (в ней должно быть мало комитов, как тут уже заметили) а просто паралельная ветка.
Мы в таких случаях мержим изменения в конце итерациий, когда код стабилен. Вместо одного болезненного мержа получаем много менее болезненных
Но вообще, даже когда у нас случались массовые мержи, вполне справлялся один человек.
Здравствуйте, tdiff, Вы писали:
T>Многим известно, что есть такой workflow, когда в определённый момент создаются т.н. "релизные" ветки, в них пушатся коммиты и в конце-концов всё это заканчивается релизом. T>При этом полагается эту ветку затем влить в "develop" ветку.
Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт?
Или вы релизами назвали feature-ветки?
T>У меня вопрос, как у вас организуется это слияние, если за время существования релизной ветки: T>1. в релизную ветку пушится много коммитов большим числом людей; T>2. в девел ветку пушится много коммитов таким же числом людей; T>3. при попытке влить релизную в девел происходит большое число конфликтов, чтобы разрезолвить которые требуется так же большое число людей.
Если само по себе возникает большое количество конфликтов — это вопрос организации самого кода и синхронизации изменений в нём и находится за пределами рассматриваемого (например, если в основной ветке пишут гуй на Qt, а в отдельной ветке на gtk, то это в принципе не мержится)
Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Здравствуйте, tdiff, Вы писали:
T>У меня вопрос, как у вас организуется это слияние, если за время существования релизной ветки:
Если отбросить мегапроекты типа win/линукса, в которых понятие центральной ветки несколько размыто, то обычно делается так:
Для svn:
1. Есть транк, в котором идёт разработка.
2. При выпуске релиза от транка отрезается tag
3. Для выпуска патча от релизной метки отрезается очередная ветка, в которую переносятся изменения из транка. Это нужно, чтобы в будущем не было проблем с клиентами, которым нужен специфический хотфикс, но не нужен сам патч. В момент выпуска патча от ветки с патчем отрезается tag (по аналогии с п.2).
4. Для разработки большой мегафичи отрезается отдельная ветка, в которую периодически (не реже, чем два раза в неделю) мержится основная ветка. Это позволяет не тратить время на обратное слияние. После закрытия фичи ветку грохаем
Здравствуйте, Kolesiki, Вы писали:
K>Неверно. "Релизная ветка" создаётся наоборот — для ограждения от изменений! Делается ветвь, которая замораживается для внесения фич и принимает только багфиксы. В день релиза собирается бинарь и публикуется, ветка "забывается". K>Когда находят критические изменения, "забытый релиз" тоже обновляется (по желанию).
Вы предлагаете багфиксы в девел не мёржить обратно?
Здравствуйте, netch80, Вы писали:
N>Эээ, тут что-то не то. Релизы вообще-то отщепляются от основных веток разработки, а не наоборот. Зачем делать по вашей схеме? Что это даёт? N>Или вы релизами назвали feature-ветки?
Нет, под релизом я имел в виду имеено ветку из которой собираются бинарники в конце концов. В нашем случае такая ветка за неделю набирает ~50 коммитов. В то же время в devel идёт разработка будущих фичей.
N>Если же вопрос стоит, что пока идут мержи, develop должна быть живой — то на это, после того, как релиз (в этой странной схеме) сделан, надо породить специальную ветку "мерж релиза X в develop", вкинуть в неё изменения из develop после форка, разгребая их (может быть, несколько раз), и только когда результат доказанно устойчив (проходит тесты и контрольные замеры) — рывком смержить в develop.
Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
Но, наверно, лучший подход зависит от степени "сложности" коммитов в релизной ветке. Если они нетривиальные, то, может быть, лучше их вмёржить один раз, а не генерировать дупликаты коммитов.
Здравствуйте, tdiff, Вы писали:
K>>Когда находят критические изменения, "забытый релиз" тоже обновляется (по желанию). T>Вы предлагаете багфиксы в девел не мёржить обратно?
В GitFlow предлагают отрезать от релиза ветку с хотфиксами и мержить из неё и в основную и в релизную ветки.
Здравствуйте, Sergey J. A., Вы писали:
SJA>Больше похоже, что это не релизная ветка (в ней должно быть мало комитов, как тут уже заметили) а просто паралельная ветка.
У нас примерно 50 коммитов за неделю набирается
SJA>Но вообще, даже когда у нас случались массовые мержи, вполне справлялся один человек.
Это сильно зависит от осведомлённости всёй команды о всём коде и о том, что вообще происходит в проекте.
Легко представить себе ситуацию, когда человеку придётся мёржить изменения двух других людей в коде, о котором он вообще не имеет представления.
В таком случае, должно сработать, как предложил netch80: сначала постепенно вливаем devel в релизную ветвь, а затем разово мёржим всё обратно в devel. Таким образом можно разбить большой сложный мёрж на несколько маленьких, которые делают разные люди.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, tdiff, Вы писали:
S>В GitFlow предлагают отрезать от релиза ветку с хотфиксами и мержить из неё и в основную и в релизную ветки.
S>Лично меня такой подход вымораживает, т.к. превращает простую и очевидную схему S>http://wiki.ci.uchicago.edu/I2U2/NewReleaseProcess S> в аццкий изврат типа такого: S>http://yakiloo.com/getting-started-git-flow/
Я не столько про хотфиксы после релиза, а в багфиксы, происходящие между отрезанием релизной ветки и релизом. Их тоже надо возвращать в основную ветку, вопрос как. В NewReleaseProcess, кстати, на этот вопрос вообще не отвечают.
Здравствуйте, tdiff, Вы писали:
T>Я не столько про хотфиксы после релиза, а в багфиксы, происходящие между отрезанием релизной ветки и релизом. T>Их тоже надо возвращать в основную ветку, вопрос как. В NewReleaseProcess, кстати, на этот вопрос вообще не отвечают.
В неправильном направлении смотришь
Если подобные факапы происходят регулярно, то тут надо не стратегии работы с ветками менять, а сам процесс разработки. Для малых и средних проектов вообще не должно быть такого, что к невыпущенному релизу уже нужен хотфикс. В основной ветке должны быть только деплоящиеся и проходящие все тесты коммиты.
Другими словами: от транка в любой момент можно отрезать релиз, пускай и не с полным набором фич, но гарантированно работающий. Если у вас не так, то никакие стратегии работы с контролем версий делу не помогут.
В порядке исключения можно конечно смержить исправления из транка в ветку для релиза, я предпочитаю переотрезать ветку для релиза.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, tdiff, Вы писали:
T>>Я не столько про хотфиксы после релиза, а в багфиксы, происходящие между отрезанием релизной ветки и релизом. T>>Их тоже надо возвращать в основную ветку, вопрос как. В NewReleaseProcess, кстати, на этот вопрос вообще не отвечают.
S>В неправильном направлении смотришь
S>Если подобные факапы происходят регулярно, то тут надо не стратегии работы с ветками менять, а сам процесс разработки. Для малых и средних проектов вообще не должно быть такого, что к невыпущенному релизу уже нужен хотфикс. В основной ветке должны быть только деплоящиеся и проходящие все тесты коммиты.
Это интересный вопрос. У нас, например, транк (он же девелоп), естественно, собирается, проходит тесты и может быть задеплоен, но из него нельзя сходу делать релиз без дополнительного тестирования. Потому что qa физически не будет успевать проверять все коммиты с той скоростью, с какой они добавляются в devel. Отсюда растёт необходимость фиксов в релизных ветках.
Здравствуйте, tdiff, Вы писали:
t> Да, это вариант. Но сейчас мы делаем по-другому: черри-пикаем каждый фикс из релизной-ветки в devel в процессе их появления. Есть подозрение, что такой вариант проще, чем разово мёржить всю ветку.
А зачем черри пик-то?? Почему не мерж? Разовый мерж да, сложнее. Но куда проще куча маленьких мержей. Если кто делает фикс в релиз, пушит, тут же делает и мерж в devel.
t> Но, наверно, лучший подход зависит от степени "сложности" коммитов в релизной ветке. Если они нетривиальные, то, может быть, лучше их вмёржить один раз, а не генерировать дупликаты коммитов.
Мелкие частые мержи — это то, что надо, собственно git под этот сценарий и заточен. Черри-пики и массовый мерж — конечно отстой.
Здравствуйте, Sinix, Вы писали:
S> В GitFlow предлагают отрезать от релиза ветку с хотфиксами и мержить из неё и в основную и в релизную ветки.
А что в этом аццкого?
S> Лично меня такой подход вымораживает, т.к. превращает простую и очевидную схему S> http://wiki.ci.uchicago.edu/I2U2/NewReleaseProcess
Это для 2007 года для SVN и прочих примитивных VCS может и нормально, ибо SVN мержить не умеет. В git, где мерж реализован, это бессмысленно, гораздо сложнее разбираться что где произошло.
T>Это интересный вопрос. У нас, например, транк (он же девелоп), естественно, собирается, проходит тесты и может быть задеплоен, но из него нельзя сходу делать релиз без дополнительного тестирования. Потому что qa физически не будет успевать проверять все коммиты с той скоростью, с какой они добавляются в devel. Отсюда растёт необходимость фиксов в релизных ветках.
А, так это тоже стандартная штука, aka тест-релиз.
Смысл в следующем: за две недели до собственно дедлайна отрезается промежуточная ветка, на ней гоняются тесты/мержатся исправления из транка и по итогам отрезается релиз.
Ну или тот же вариант, только наизнанку:
За те же две недели до релиза разработка переходит в режим закрытия технического долга, чинится только мелочёвка, новые фичи уезжают в отдельные ветки.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, tdiff, Вы писали:
T>>Это интересный вопрос. У нас, например, транк (он же девелоп), естественно, собирается, проходит тесты и может быть задеплоен, но из него нельзя сходу делать релиз без дополнительного тестирования. Потому что qa физически не будет успевать проверять все коммиты с той скоростью, с какой они добавляются в devel. Отсюда растёт необходимость фиксов в релизных ветках.
S>За те же две недели до релиза разработка переходит в режим закрытия технического долга, чинится только мелочёвка, новые фичи уезжают в отдельные ветки.
Вот именно это я и называю "релизной веткой". Вопрос был про то, когда мёржить из неё в транк: каждый коммит отдельно или в конце всё вместе.
Если второе — то как это организуется технически, потому что там потенциально могут быть конфликты в разных частях кода, которые должны мёржить разные люди. В принципе, netch80 предложил нормальный вариант, как мне кажется.
Здравствуйте, ·, Вы писали:
·>А зачем черри пик-то?? Почему не мерж? Разовый мерж да, сложнее. Но куда проще куча маленьких мержей. Если кто делает фикс в релиз, пушит, тут же делает и мерж в devel. ·>Мелкие частые мержи — это то, что надо, собственно git под этот сценарий и заточен. Черри-пики и массовый мерж — конечно отстой.
Мы в целом у себя стараемся делать как можно меньше мёржей. Не потому, что не умеем или боимся, а для того, чтобы как можно проще и линейней была история в репозитории. Но то, что так можно делать, в принципе, я согласен.
Здравствуйте, tdiff, Вы писали:
t> ·>А зачем черри пик-то?? Почему не мерж? Разовый мерж да, сложнее. Но куда проще куча маленьких мержей. Если кто делает фикс в релиз, пушит, тут же делает и мерж в devel. t> ·>Мелкие частые мержи — это то, что надо, собственно git под этот сценарий и заточен. Черри-пики и массовый мерж — конечно отстой.
t> Мы в целом у себя стараемся делать как можно меньше мёржей. Не потому, что не умеем или боимся, а для того, чтобы как можно проще и линейней была история в репозитории. Но то, что так можно делать, в принципе, я согласен.
А почему же? Сложные и страшные мержи "а тут у нас всё вдруг поменялось" не делают историю проще.
Линейность истории тоже не самоцель. Если история и в самом деле нелинейная по своей природе... зачем её насильно линеаризовать?
Здравствуйте, ·, Вы писали:
S>> В GitFlow предлагают отрезать от релиза ветку с хотфиксами и мержить из неё и в основную и в релизную ветки. _>А что в этом аццкого?
Ну как — это нормально работает только если поддерживается только предыдущий релиз. Во всех остальных случаях начинается бардак.
Вариант с общим сторилайном, когда все исправления сначала попадают в основную ветку, там проверяются и уже потом переносятся в ветку (ветки) для хотфикса, выглядит гораздо логичней, чем обратный подход, когда у нас история скачет
dev -> master -> release -> hotfix -> dev
Я честно не могу понять особой необходимость в таких приседаниях для локально разрабатываемого проекта.
Ну и ещё, почти везде одновременно с введением gitflow пытаются ещё и отказаться от регулярных мержей из основной ветки в ветки для feature. Я честно не знаю откуда оно пошло, тем более, что в самом GitFlow про подхват изменений емнип ничего не сказано, но тынденция такая определённо есть
S>> http://wiki.ci.uchicago.edu/I2U2/NewReleaseProcess _>Это для 2007 года для SVN и прочих примитивных VCS может и нормально, ибо SVN мержить не умеет. В git, где мерж реализован, это бессмысленно, гораздо сложнее разбираться что где произошло.
В смысле? Там просто ветки для фич пропущены, ибо они никак не влияют на процесс выпуска релиза. Мерж транк<>feature в svn где-то с 1.7 проблем никаких не вызывает, вот со всеми остальными сценариями — всё та же боль-печаль, да.
)
