Здравствуйте, Sinix, Вы писали:
S> S>> В GitFlow предлагают отрезать от релиза ветку с хотфиксами и мержить из неё и в основную и в релизную ветки. S> _>А что в этом аццкого? S> Ну как — это нормально работает только если поддерживается только предыдущий релиз. Во всех остальных случаях начинается бардак.
Бардак если пытаться хотфикс сделать в dev, а не в старинной версии. Уже весь код может быть перелопачен, классов таких нет... какой смысл в dev это пытаться фиксить, если потом, при переносе (cherry-pick притом только, возможно даже массовый) в хотфикс возникнут страшные конфликты... тратится время на выпуск хотфикса, который на то и "хот", что его нужно прямо сейчас. В дев можно замержить попозже, когда хотфикс зарелизен. И, притом, мерж из старой версии в новую обычно проще и естественнее чем наоборот.
S> Вариант с общим сторилайном, когда все исправления сначала попадают в основную ветку, там проверяются и уже потом переносятся в ветку (ветки) для хотфикса, выглядит гораздо логичней, чем обратный подход, когда у нас история скачет S> dev -> master -> release -> hotfix -> dev
Да почему логичнее? Хотфиксится не dev, а release.
S> Я честно не могу понять особой необходимость в таких приседаниях для локально разрабатываемого проекта.
Да нет никаких приседаний особых, по крайней мере в git.
S> Ну и ещё, почти везде одновременно с введением gitflow пытаются ещё и отказаться от регулярных мержей из основной ветки в ветки для feature. Я честно не знаю откуда оно пошло, тем более, что в самом GitFlow про подхват изменений емнип ничего не сказано, но тынденция такая определённо есть
Не знаю... да, не логично. По-моему надо наоборот почаще основую ветку в feature подсасывать.
feature-ветки мне вообще в последнее время кажутся злом. Надо это делать в самом коде, тупой if.
S> S>> http://wiki.ci.uchicago.edu/I2U2/NewReleaseProcess S> _>Это для 2007 года для SVN и прочих примитивных VCS может и нормально, ибо SVN мержить не умеет. В git, где мерж реализован, это бессмысленно, гораздо сложнее разбираться что где произошло. S> В смысле? Там просто ветки для фич пропущены, ибо они никак не влияют на процесс выпуска релиза. Мерж транк<>feature в svn где-то с 1.7 проблем никаких не вызывает, вот со всеми остальными сценариями — всё та же боль-печаль, да.
Эта картинка нарисована в 2007, когда svn мержить не умел вообще, там по-другому в принципе нельзя без боли-печали. Сейчас тоже не умеет, впрочем, svn:mergeinfo это же извращение и грязный хак какой-то.
Здравствуйте, tdiff, Вы писали:
S>>За те же две недели до релиза разработка переходит в режим закрытия технического долга, чинится только мелочёвка, новые фичи уезжают в отдельные ветки. T>Вот именно это я и называю "релизной веткой". Вопрос был про то, когда мёржить из неё в транк: каждый коммит отдельно или в конце всё вместе.
Не, в закрытии техдолга транк так и остаётся транком, из него отрезается релиз и после этого все, кто писал что-то новое сливаются обратно в транк.
А вот в режиме тест-релиза все исправления сначала делаются в транке, затем переносятся в тест-релизную ветку, и из неё отрезается метка релиза.
Правило большого пальца такое: направление переноса должно быть всегда из основной ветки, за исключением случая, когда ветку закрывают. Иначе начинается путаница при необходимости выпускать релизы одновременно для нескольких версий.
для тест-релиза:
=== trunk
--- branch
// new branch
/ grab changes from trunk
c commit
fс fix release commit
m merged commit
x closed branch
-release-tag-X
//
-pre-release---m---m----x
// / /
==trunk=======c=======fc==fc======...
\\ \ \ \ //
feature--m---c---m---m---x
Здравствуйте, Sinix, Вы писали:
S> Правило большого пальца такое: направление переноса должно быть всегда из основной ветки, за исключением случая, когда ветку закрывают. Иначе начинается путаница при необходимости выпускать релизы одновременно для нескольких версий.
Если несколько версий, я бы начинал с самой старой. Вначале изменение вносится в самый старый релиз, тестируется, релизится.
Потом мержится в следующий, притом вполне могут быть конфликты, т.к. более новая версия может быть сильно изменена. Конфликты разрешаются точно так же как раньше, по знакомому сценарию.
Скажем, был метод setName, в версии v1, его переименовали в setFullName в версии v2. Если мержить, от старого к новому — делаешь уже то что делал раньше — заменяешь использование setName на setFullName.
В твоём варианте изменять придётся в обратную сторону, так называемый backport, который совсем другая история... гладишь против шерсти.
Такие переносы можно осуществлять только cherry-pick — делая копии коммитов, вместо естественного merge.
А в моём варианте получается красивый естественный DAG.
При условии что "m" коммиты в pre-release это и правда merge, а не cherry-pick, то такая схема не сработает. А cherry-pick — куча бед и боли, неинтересно, пусть с этим svn-щики мучаются.
Здравствуйте, tdiff, Вы писали:
S>>Если подобные факапы происходят регулярно, то тут надо не стратегии работы с ветками менять, а сам процесс разработки. Для малых и средних проектов вообще не должно быть такого, что к невыпущенному релизу уже нужен хотфикс. В основной ветке должны быть только деплоящиеся и проходящие все тесты коммиты.
T>Это интересный вопрос. У нас, например, транк (он же девелоп), естественно, собирается, проходит тесты и может быть задеплоен, но из него нельзя сходу делать релиз без дополнительного тестирования. Потому что qa физически не будет успевать проверять все коммиты с той скоростью, с какой они добавляются в devel. Отсюда растёт необходимость фиксов в релизных ветках.
+1. Вообще, график разработки придумали не зря. В зелёной зоне релизить нельзя, сколь качественным ни был бы код на входе. Форк релизного бранча, цикл тестов, правки (уже не столь важно, в транк из релизной или наоборот мержатся/чирикаются/etc.), и только тогда "нарезать болванки".
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Sinix, Вы писали: ·>Потом мержится в следующий, притом вполне могут быть конфликты, т.к. более новая версия может быть сильно изменена. Конфликты разрешаются точно так же как раньше, по знакомому сценарию. ·>Скажем, был метод setName, в версии v1, его переименовали в setFullName в версии v2. Если мержить, от старого к новому — делаешь уже то что делал раньше — заменяешь использование setName на setFullName.
·>В твоём варианте изменять придётся в обратную сторону, так называемый backport, который совсем другая история... гладишь против шерсти. ·>Такие переносы можно осуществлять только cherry-pick — делая копии коммитов, вместо естественного merge.
Ну в моём отделе работали именно через cherry-picks из транка, а в соседнем отделе — часто делали по схеме, которую ты описываешь. В принципе ничего плохого в cherry-picks я не находил. Да, иногда надо цепочку из 10-20 коммитов перекинуть по одному, заодно по дороге проверяя каждую тонкость. Но польза в понятной (и линейной!) логике может оказаться выше даже для тех, кто давно забыл, что такое CVS/SVN/etc. и привык к мержам.
(Интересно, что тот соседний отдел, работая по такой схеме, не мог объяснить, как же она работает. Я пытался понять, но тогда не хватило опыта. А они не умели внятно объяснять, хотя сами так работали. Это ещё одна проблема такого подхода.)
·>А в моём варианте получается красивый естественный DAG.
Да, получается. Но ещё сама схема требует высокой культуры — проверять, что получается в случае такого мержа.
К слову — без установки хотя бы merge.conflictstyle=diff3 работать с мержами чего-то нетривиального невозможно в принципе.
Меня в этой "простой и очевидной" вымораживает пример "2.0 не получилась, делаем 2.1". Какое отношение номера версий имеют к пробам сборки и тестирования, и какая религия запрещает сделать фикс и смержить его вверх?
S> в аццкий изврат типа такого: S>http://yakiloo.com/getting-started-git-flow/
Если не относиться чрезмерно лободробительно к этой схеме, это всего лишь комплекс мер по достаточно качественной предварительной оценке изменений и защите продакшена и пользователей от непроработанных решений, при отсутствии высоких требований к разработчикам (считаем, они не в состоянии сами выпутаться из ситуации работы нескольких человек над одной веткой).
Здравствуйте, netch80, Вы писали:
n> Ну в моём отделе работали именно через cherry-picks из транка, а в соседнем отделе — часто делали по схеме, которую ты описываешь. В принципе ничего плохого в cherry-picks я не находил. Да, иногда надо цепочку из 10-20 коммитов перекинуть по одному, заодно по дороге проверяя каждую тонкость. Но польза в понятной (и линейной!) логике может оказаться выше даже для тех, кто давно забыл, что такое CVS/SVN/etc. и привык к мержам. n> (Интересно, что тот соседний отдел, работая по такой схеме, не мог объяснить, как же она работает. Я пытался понять, но тогда не хватило опыта. А они не умели внятно объяснять, хотя сами так работали. Это ещё одна проблема такого подхода.)
cherry-picks плохи тем, что это копии коммитов. Трудно отслеживать, а что же именно было запикано, а что нет. Мерж всё просто — коммит в истории, значит замержен.
Честно говоря удивительно, почему это так трудно другим даётся. Мне лично кажется что git с его нелинейной историей гораздо проще для понимания, чем тот же svn, ибо нелинейная история отображает реальное положение вещей — соответствует ровно тому как шел процесс разработки.
n> ·>А в моём варианте получается красивый естественный DAG. n> Да, получается. Но ещё сама схема требует высокой культуры — проверять, что получается в случае такого мержа.
Cherry-pick эту проверку не отменяет, и даже не упрощает.
n> К слову — без установки хотя бы merge.conflictstyle=diff3 работать с мержами чего-то нетривиального невозможно в принципе.
Массовые cherry-pick будут давать не меньше (а чаще больше) конфликтов чем мержи.
Скажем, две-три неудачные зареверченные попытки пофиксить баг с замерженные одним махом, дадут меньше конфликтов, скорее всего, чем их массовый черри-пик. А если черри-пикать не всё, а частично, но нужно очень внимательно вникать в каждый коммит и выбирать что точно нужно, а что не очень. В общем простора для ошибок больше.
Здравствуйте, netch80, Вы писали:
N>Меня в этой "простой и очевидной" вымораживает пример "2.0 не получилась, делаем 2.1". Какое отношение номера версий имеют к пробам сборки и тестирования, и какая религия запрещает сделать фикс и смержить его вверх?
Согласен, конкретно эта идея дурацкая. Взял первый похожий на правду результат из гугла, этого нюанса не заметил
S>> в аццкий изврат типа такого: S>>http://yakiloo.com/getting-started-git-flow/
N>Если не относиться чрезмерно лободробительно к этой схеме, это всего лишь комплекс мер по достаточно качественной предварительной оценке изменений и защите продакшена и пользователей от непроработанных решений, при отсутствии высоких требований к разработчикам (считаем, они не в состоянии сами выпутаться из ситуации работы нескольких человек над одной веткой).
Хз. Для меня это выглядит как попытка натянуть успешную схему для опенсорса (тут и она, и github flow очень даже ничего) на типовую локальную разработку.
1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?
2. Зачем идиотская схема с "чиним заново тикет на релизной ветке" вместо простого бэкпорта с основной ветки (обычно примерно в половине случаев исправление уже там есть)? Какой порядок действий для нескольких релизов? UPD. Вопрос отпал. Забыл, что гит не отслеживает cherry picks. Жизнь — боль, ага.
3. Какого чёрта почти все "внедренцы" требуют не мержить без явной необходимости ничего из основной ветки в feature??? Типа стрелочки на диаграмме нет — значит низзя?
В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде
Здравствуйте, ·, Вы писали:
·>Бардак если пытаться хотфикс сделать в dev, а не в старинной версии.
Ага, кажется понял в чём дело. Фигню спорим
У нас с вами разные процессы разработки, потому что для вас вот такие моменты важны:
Бардак если пытаться хотфикс сделать в dev, а не в старинной версии. Уже весь код может быть перелопачен, классов таких нет... какой смысл в dev это пытаться фиксить, если потом, при переносе (cherry-pick притом только, возможно даже массовый) в хотфикс возникнут страшные конфликты...
а у нас я с трудом вспоминаю, когда последний сложный конфликт мержа был
Года два что ли назад.
При этом и файлы активно правятся, и переименование тож регулярно. Фиг его знает почему, но подобных проблем не возникает — значит и мер специальных для них не предпринимаем.
И ещё различие: где-то в 3/4 случаях у нас ошибки уже починены в транке + отлажены + проверены самыми свежими версиями тестов. Т.е. экономически выгоднее их бэкпортить, чем поднимать у разработчика окружение для нескольких старых версий, воспроизводить ошибку, чинить, проверять и затем повторять всё то же самое на основной ветке.
·>При условии что "m" коммиты в pre-release это и правда merge, а не cherry-pick, то такая схема не сработает. А cherry-pick — куча бед и боли, неинтересно, пусть с этим svn-щики мучаются.
EDIT Мдя, забыл, что git не умеет отслеживать cherry-pick Ну тогда да, только с мержами развлекаться. EDIT2 Фейспалм к "забыл", не к "git не умеет" относится. Неоднозначно получилось
Не в порядке спора
Типовая ситуация: есть ошибка, на текущей версии не воспроизводится, найти коммит (коммиты) с исправлением по логу — две минуты.
Дальше я вижу только один вариант: переносим коммиты в ветку для хотфикса, проверяем сами, отдаём на тестирование. Т.е. да, cherrypick во весь рост.
Делитесь, как ещё можно разрулить такую ситуацию?
Здравствуйте, ·, Вы писали:
·>cherry-picks плохи тем, что это копии коммитов. Трудно отслеживать, а что же именно было запикано, а что нет. Мерж всё просто — коммит в истории, значит замержен.
Это ты по commit-ids следишь? Если они не меняются — да, это работает. С другой стороны, у нас был gerrit, у которого свои id. И по ним следить было легче — cherry-pick их не меняет.
А ещё твой метод работает только тогда, когда есть, грубо говоря, два типа веток — релизные без исправлений после форка от транка (разве что version.h исправить) и рабочие всех видов, сходящиеся в транк. В то же время у многих проектов есть
1) форк major-ветки на этапе концептуальной фиксации набора фич конкретного мажора
2) разработка в major-ветке каких-то фич, которые не переносятся в транк, потому что завязаны на специфику именно этого мажорного релиза (вспомним, например, 1С 7 поверх dbf и 8 поверх sql)
n>> ·>А в моём варианте получается красивый естественный DAG. n>> Да, получается. Но ещё сама схема требует высокой культуры — проверять, что получается в случае такого мержа. ·>Cherry-pick эту проверку не отменяет, и даже не упрощает.
Вот тут есть нюанс, что та проверка, что глазами (а это почти всегда необходимая часть) — сильно легче при коммитах по одному (особенно когда грамотно разделены правки функциональности, стиля и рефакторинга) и почти невозможна в случае мержа — диффы могут быть на десятки тысяч строк в сторону любого источника.
n>> К слову — без установки хотя бы merge.conflictstyle=diff3 работать с мержами чего-то нетривиального невозможно в принципе. ·>Массовые cherry-pick будут давать не меньше (а чаще больше) конфликтов чем мержи.
Да, но каждый из них решается проще за счёт меньшего объёма изменения.
·>Скажем, две-три неудачные зареверченные попытки пофиксить баг с замерженные одним махом, дадут меньше конфликтов, скорее всего, чем их массовый черри-пик.
Ой, в случае ревертов таки надо осторожнее — сливать их в один. Я на реверты не рассчитываю, они у нас были в редчайших случаях.
·> А если черри-пикать не всё, а частично, но нужно очень внимательно вникать в каждый коммит и выбирать что точно нужно, а что не очень. В общем простора для ошибок больше.
Здравствуйте, Sinix, Вы писали:
S>>>http://yakiloo.com/getting-started-git-flow/
N>>Если не относиться чрезмерно лободробительно к этой схеме, это всего лишь комплекс мер по достаточно качественной предварительной оценке изменений и защите продакшена и пользователей от непроработанных решений, при отсутствии высоких требований к разработчикам (считаем, они не в состоянии сами выпутаться из ситуации работы нескольких человек над одной веткой).
S>Хз. Для меня это выглядит как попытка натянуть успешную схему для опенсорса (тут и она, и github flow очень даже ничего) на типовую локальную разработку.
S>1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?
Именно тем, что форки. Представь себе контору не на 20 себя, а на 2000 Ражалпрограм Абдулкумаров, среди которых иногда попадается менее тупой, но в разы более опасный Кришназевул (как правило, он руководит отделом и профессионально умеет подсиживать кого угодно). Ещё не страшно? Теперь надо всем этим руководить, не давая повода для драк прямо в офисе на тему "ты, сын шакала, правнук дэва, мне фичу запорол, у меня не мержится без конфликта, ты метод удалил, через который я всё делал".
В случае же персональных веток картина другая: когда абдулкумар закончит фичу — ему придётся адаптироваться под развитие, созданное не одним кумаршайтаном с соседнего стола, а десятками таких. Сразу исчезает причина бить кого-то одного, а против целого офиса ему не выстоять. Приходится адаптироваться под общее развитие.
Думаешь, я утрирую? По-моему, с первого взгляда видно, что git-flow рассчитан именно на такой программный комбинат — серпентарий, а не на дружную группу с точно общей целью. И от замены стиля имён и этноса персоналий характер процессов меняется только в плане времени, проходящего до возможной драки, и практик использования подручных предметов.
А ещё проверяющий сверху может получить список коммитов конкретного самца — производителя не вычитыванием по имени из длинной плетёнки, а ткнув в конкретную ветку — быстро и наглядно.
S>2. Зачем идиотская схема с "чиним заново тикет на релизной ветке" вместо простого бэкпорта с основной ветки (обычно примерно в половине случаев исправление уже там есть)? Какой порядок действий для нескольких релизов? S>UPD. Вопрос отпал. Забыл, что гит не отслеживает cherry picks. Жизнь — боль, ага.
Вот потому есть ключик -x для cherry-pick и Change-Id у Gerrit. Я вообще подумываю привинтить герритовский хук для генерации Change-Id даже там, где работаем без Gerrit: удобно же.
S>3. Какого чёрта почти все "внедренцы" требуют не мержить без явной необходимости ничего из основной ветки в feature??? Типа стрелочки на диаграмме нет — значит низзя?
Не знаю, мне как-то не приходилось участвовать в ритуале вызова демона скрам-мастера и прочих потусторонних сущностей. Но, думаю, и среди них есть разные школы, вплоть до находящихся в войне до полного истребления.
S>В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде
Нет, это разработка, втиснутая в жёсткие иерархические подходы. Возможно, даже военные. Если во главе комбината отставной генерал-майор мотокавалерийских десантных сил субарктического реагирования — ему это подойдёт идеально.
S>>1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?
N>Именно тем, что форки. Представь себе контору не на 20 себя, а на 2000 Ражалпрограм Абдулкумаров
А. Ну так мы разные вещи обсуждаем тогда
Я про типовой энтерпрайз писал, где 5-7 групп из десятка девелоперов на одном проекте — это уже много
Даже что-то типа дисклаймера в начале ветки было,
Если отбросить мегапроекты типа win/линукса, в которых понятие центральной ветки несколько размыто ...
На твоих масштабах вся эта кухня понятна и нужна. Чего остальным делать?
S>>UPD. Вопрос отпал. Забыл, что гит не отслеживает cherry picks. Жизнь — боль, ага. N>Вот потому есть ключик -x для cherry-pick и Change-Id у Gerrit. Я вообще подумываю привинтить герритовский хук для генерации Change-Id даже там, где работаем без Gerrit: удобно же.
Ну вот да. В очередной раз убеждаюсь, что к гиту должен прилагаться человек, который не "я ж читал", а уже умеет готовить кошек, хотя бы на первых этапах внедрения. Где бы их найти ещё?
S>>В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде N>Нет, это разработка, втиснутая в жёсткие иерархические подходы. Возможно, даже военные. Если во главе комбината отставной генерал-майор мотокавалерийских десантных сил субарктического реагирования — ему это подойдёт идеально.
Ага, "ну, или так"(с).
Тогда вопрос такой: не попадалось подхода, заточенного под типовую локальную энтерпрайз-разработку, но с учётом всех нюансов гита?
Т.е 99% работы — это update/commit (в трактовке svn) и максимально дуракоустойчиво. Понятно, что при таком раскладе надо бы использовать svn и не сношать мозги, но здравый смысл побеждает не всегда
Потому что пока попадался или адаптированный гитхаб (очень ничего, но для полной красоты надо бы код на отдельные минипроекты (пакеты) разбивать), или gitflow в пересказе Рабиновича, или "нажимать сюда, если что, зовите, иначе поломаете всё".
Здравствуйте, Sinix, Вы писали:
S> 1. Серьёзно, зачем городить изврат с master-dev ветками? Чем оно удобнее основной ветки + отдельной ветки для каждого релиза? Понятно, что оно обязательно для форков. Для не-опенсорса зачем?
Это общая схема. Не обязательно использовать всё.
master-ветка может быть публичной, доступной 3rd-party, когда develop это для внутренней разработки.
S> 2. Зачем идиотская схема с "чиним заново тикет на релизной ветке" вместо простого бэкпорта с основной ветки (обычно примерно в половине случаев исправление уже там есть)? Какой порядок действий для нескольких релизов?
"починка" может выглядеть как cherry-pick, если уже и правда пофикшено одним отдельным коммитом, а в общем случае такое далеко не всегда бывает. Гит без проблем мержит черри-пики.
Если новый баг, то правильнее взять релизную версию и там попытаться воспроизвести и пофиксить.
Каждый релиз в любом случае надо брать и тестировать с каждым кандидатом.
S> 3. Какого чёрта почти все "внедренцы" требуют не мержить без явной необходимости ничего из основной ветки в feature??? Типа стрелочки на диаграмме нет — значит низзя?
Хз, не знаю. Фтопку внедренцев.
S> В общем, может где-то и есть более-менее человеческое описание "как адаптировать gitflow к типовой энтерпрайз-разработке", но пока всё что попадалось — это именно культ карго в чистом виде
Можно брать какое-то подмножество gitflow. Скажем, выкинуть master и feature ветки.
Самый простой как-то так:
Здесь нарисован такой сценарий.
1. Выпустили v1.0
2. выпустили v2.0
3. нашли багу в v2.0 сделали хотфикс, выпустили v2.1.
4. Нашли багу в v1.0, сделали хотфикс, выпустили v1.1
5. замержили этот же хотфикс в v2.1 и выпустили v2.2.
master
|
|
c-<v1.0>
|\_____
c |
| h-<v1.1>
c \
| |
с |
| |
c-<v2.0>\_______
|\____ |
c | |
| h-<v2.1> |
c ___/| ________/
|/ |/
m m-<v2.2>
| /
c ___|
|/
m
|
c
Где c это обычные изменения. h — хотфиксы, m — мержи.
Вообще — одна единственная ветка, остальное теги.
Ветка master содержит все изменения и и хотфиксы.
Здравствуйте, netch80, Вы писали:
n> ·>cherry-picks плохи тем, что это копии коммитов. Трудно отслеживать, а что же именно было запикано, а что нет. Мерж всё просто — коммит в истории, значит замержен. n> Это ты по commit-ids следишь? Если они не меняются — да, это работает. С другой стороны, у нас был gerrit, у которого свои id. И по ним следить было легче — cherry-pick их не меняет.
Да, они самые просые. Скажем "git branch --contains <commit>" сразу выдаёт ветки. С cherry-pick надо приседать и подпрыгивать.
n> А ещё твой метод работает только тогда, когда есть, грубо говоря, два типа веток — релизные без исправлений после форка от транка (разве что version.h исправить) и рабочие всех видов, сходящиеся в транк. В то же время у многих проектов есть n> 1) форк major-ветки на этапе концептуальной фиксации набора фич конкретного мажора n> 2) разработка в major-ветке каких-то фич, которые не переносятся в транк, потому что завязаны на специфику именно этого мажорного релиза (вспомним, например, 1С 7 поверх dbf и 8 поверх sql)
Такие вещи проще на уровне кода разруливать. Собственно задумываться о том как сделать код branch-friendly тоже необходимо.
n> n>> Да, получается. Но ещё сама схема требует высокой культуры — проверять, что получается в случае такого мержа. n> ·>Cherry-pick эту проверку не отменяет, и даже не упрощает. n> Вот тут есть нюанс, что та проверка, что глазами (а это почти всегда необходимая часть) — сильно легче при коммитах по одному (особенно когда грамотно разделены правки функциональности, стиля и рефакторинга) и почти невозможна в случае мержа — диффы могут быть на десятки тысяч строк в сторону любого источника.
Так я и говорю, что мержи нужно делать маленькими. Можно хоть одиночные коммиты мержить.
cherry-pick сотни коммитов — та же, а то и бОльшая проблема, что и мерж сотни коммитов.
n> ·>Массовые cherry-pick будут давать не меньше (а чаще больше) конфликтов чем мержи. n> Да, но каждый из них решается проще за счёт меньшего объёма изменения.
С чего это вдруг? "Черри-пик 100 коммитов" >= "мерж 100 коммитов".
n> ·>Скажем, две-три неудачные зареверченные попытки пофиксить баг с замерженные одним махом, дадут меньше конфликтов, скорее всего, чем их массовый черри-пик. n> Ой, в случае ревертов таки надо осторожнее — сливать их в один. Я на реверты не рассчитываю, они у нас были в редчайших случаях.
Зачем сливать?! Да и не всегда возможно. реверты можно делать и в разные моменты времени.
Здравствуйте, Sinix, Вы писали:
S> Ага, кажется понял в чём дело. Фигню спорим
Хм, удивил. Как обычно.
S> а у нас я с трудом вспоминаю, когда последний сложный конфликт мержа был S> Года два что ли назад. S> При этом и файлы активно правятся, и переименование тож регулярно. Фиг его знает почему, но подобных проблем не возникает — значит и мер специальных для них не предпринимаем.
А вы правда поддерживаете несколько версий? Т.е. пилите v10, а клиент вдруг обнаруживает баг в v2, выпушенной 3 года назад и хочет чтобы исправили, и быстро.
S> И ещё различие: где-то в 3/4 случаях у нас ошибки уже починены в транке + отлажены + проверены самыми свежими версиями тестов. Т.е. экономически выгоднее их бэкпортить, чем поднимать у разработчика окружение для нескольких старых версий, воспроизводить ошибку, чинить, проверять и затем повторять всё то же самое на основной ветке.
Так пытаться воспроизвести и проверять фикс на старой версии _обязательно_. Иначе как ты докажешь что ты поправил именно тот баг, а не похожий, и исправление применённое на транке ничего не ломает в старой версии? Сразу скажу, что "мамой клянус" за доказательство не принимаю.
Здравствуйте, ·, Вы писали:
S>> При этом и файлы активно правятся, и переименование тож регулярно. Фиг его знает почему, но подобных проблем не возникает — значит и мер специальных для них не предпринимаем. _>А вы правда поддерживаете несколько версий? Т.е. пилите v10, а клиент вдруг обнаруживает баг в v2, выпушенной 3 года назад и хочет чтобы исправили, и быстро.
Не, это уже экзотика и тогда твой вариант разумеется правильный будет.
Для нас куда важнее возможность выпустить индивидуальный патч для конкретного клиента (он редко сидит на версии дольше, чем годовой давности) + регулярно выпускать обновлениями с мелкими фичами/дополнениями, что-то по аналогии с vs update, только мы их чаще лепим, конечно. На svn это делается элементарно, выборочным merge.
Как тут быть с гитом — хз, на нём проектов с такими требованиями не попадалось.
_>Так пытаться воспроизвести и проверять фикс на старой версии _обязательно_. Иначе как ты докажешь что ты поправил именно тот баг, а не похожий, и исправление применённое на транке ничего не ломает в старой версии? Сразу скажу, что "мамой клянус" за доказательство не принимаю.
А это уже ответственность выпускающего тест разработчика + qa + тесты на билд-сервере. Чинящему достаточно проверить корректность на текущей версии и залить в транк. За счёт такого разделения труда (одни чинят, другой переносит) на старую версию откатываться надо только одному человеку.
Тут сразу надо оговориться: по-моему, такой подход хорошо работает, только если весь код выполнен в srp-стиле.
Например, в виде кучи микросервисов + контракт каждого сервиса задокументирован интерфейсом. Тогда после мержа дифф двух папок достаточно чётко показывает объём работ по проверке.
Здравствуйте, Sinix, Вы писали:
N>>Именно тем, что форки. Представь себе контору не на 20 себя, а на 2000 Ражалпрограм Абдулкумаров S>А. Ну так мы разные вещи обсуждаем тогда S>Я про типовой энтерпрайз писал, где 5-7 групп из десятка девелоперов на одном проекте — это уже много
Видно, понятие "типовой энтерпрайз" сильно размыто. Такое понятие западного менеджмента, как "workgroup" (помнишь Windows for workgroups?), обычно подразумевает до 100 человек, а у нас — до 10.
S>Даже что-то типа дисклаймера в начале ветки было, S>
S>Если отбросить мегапроекты типа win/линукса, в которых понятие центральной ветки несколько размыто ...
S>На твоих масштабах вся эта кухня понятна и нужна. Чего остальным делать?
1. Это не мои масштабы Мои это 5-20 человек на одно репо, а на текущей работе вообще 2-5.
2. Git тем и хорош, что он для масштабов от одного робота (даже не человека) и до десятков тысяч человек работает вполне неплохо. Разумеется, везде чуть по-своему, но позволяет выживать в таких условиях с разными схемами.
S>>>UPD. Вопрос отпал. Забыл, что гит не отслеживает cherry picks. Жизнь — боль, ага. N>>Вот потому есть ключик -x для cherry-pick и Change-Id у Gerrit. Я вообще подумываю привинтить герритовский хук для генерации Change-Id даже там, где работаем без Gerrit: удобно же. S>Ну вот да. В очередной раз убеждаюсь, что к гиту должен прилагаться человек, который не "я ж читал", а уже умеет готовить кошек, хотя бы на первых этапах внедрения. Где бы их найти ещё?
Это для любой системы. А для распределённой — особенно нужен специалист по распределённым. Специфика Git тут меньше значит по сравнению с общей проблематикой — разве что его специфические возможности типа перекроить всё и вся через rebase.
S>Тогда вопрос такой: не попадалось подхода, заточенного под типовую локальную энтерпрайз-разработку, но с учётом всех нюансов гита? S>Т.е 99% работы — это update/commit (в трактовке svn) и максимально дуракоустойчиво. Понятно, что при таком раскладе надо бы использовать svn и не сношать мозги, но здравый смысл побеждает не всегда
SVN мне лично как-то не идёт и не идёт — несмотря на много лет на CVS, хотя это должно было влиять в пользу SVN. Ну просто какое-то нелепое оно. А так — боюсь, тебе таки придётся от общих фраз типа "типовую локальную энтерпрайз-разработку" перейти к конкретным цифрам (сколько человек на репо, коммитов, среднем одновременно поддерживаемых релизов и разрабатываемых фич, необходимость и требования к ревью, и т.д.)
Здравствуйте, Sinix, Вы писали:
S> S>> При этом и файлы активно правятся, и переименование тож регулярно. Фиг его знает почему, но подобных проблем не возникает — значит и мер специальных для них не предпринимаем.
S> _>А вы правда поддерживаете несколько версий? Т.е. пилите v10, а клиент вдруг обнаруживает баг в v2, выпушенной 3 года назад и хочет чтобы исправили, и быстро.
S> Не, это уже экзотика и тогда твой вариант разумеется правильный будет. S> Для нас куда важнее возможность выпустить индивидуальный патч для конкретного клиента (он редко сидит на версии дольше, чем годовой давности) + регулярно выпускать обновлениями с мелкими фичами/дополнениями, что-то по аналогии с vs update, только мы их чаще лепим, конечно. На svn это делается элементарно, выборочным merge. S> Как тут быть с гитом — хз, на нём проектов с такими требованиями не попадалось.
Да так же, выборочным cherry-pick.
S> _>Так пытаться воспроизвести и проверять фикс на старой версии _обязательно_. Иначе как ты докажешь что ты поправил именно тот баг, а не похожий, и исправление применённое на транке ничего не ломает в старой версии? Сразу скажу, что "мамой клянус" за доказательство не принимаю. S> А это уже ответственность выпускающего тест разработчика + qa + тесты на билд-сервере. Чинящему достаточно проверить корректность на текущей версии и залить в транк. За счёт такого разделения труда (одни чинят, другой переносит) на старую версию откатываться надо только одному человеку.
Так просто чинить надо в старой версии. Т.е. тот кто чинит — чинит именно то что надо починить.
А тот кто будет мержить в транк — тому старая версия не нужна, просто git merge hotfix.
Да и вообще, откатываться на старую версию только в svn проблема, занимает кучу времени для большого объёма исходников. git checkout работает секунду-две.
Ну тогда да, только с мержами развлекаться.
