M>Нигде не встречал работу в мастер-бранчем через постоянные merge. Только rebase, PR, squash and merge.

Бывает такое, если есть отдельные maintenance branches.
Например, был релиз 1.0, теперь все багфиксы для релиза 1.0 идут в ту ветку (maint-1), но в master попадают тоже, через merge commit.

Здравствуйте, ·, Вы писали:

vsb>>>>·>Кстати. Если подумать, то мерж по большому счёту немного про другое. Это когда у тебя сложный продукт со множеством поддерживаемых версий. Т.е. обнаружили багу в JDK, выяснили, что она тянется аж с java8. Пофиксили в java8, а потом это всё замержили и в java11, 17 и master.
N>>Не получится замержить, код сильно разный.
·>_Если_ будет конфликт — зарезолвим. В этом и суть мержей — сливать разный код и разрешать конфликты если сильно разный.

Для настоящего мержа нужна общая база истории, причём честная. И зачем её тут такую поддерживать?

N>>·> cherry-picking обычно нужен для бэкпортов. Например, поправили багу в 17й версии. Вылез клиент, сидящий на версии 8, не желающий переезжать на 17ю, но готовый заплатить за фикс этой баги. Вот для него зачеррипикаем те фиксы, которые он хочет поверх версии на которой он сидит.
N>>А могли начать фиксить в 8-й и черипиками доползти вверх до 17-й. Разницы по сути никакой.
·>Разница в графе истории. Так у тебя две навечно разъехавшиеся ветки, сравнить которые нет никакой возможности. А если в графе настоящие мержи, то всё как на ладони.

Зачем их вообще _так_ сравнивать?

vsb>>>>А куда тут мердж засунуть, я вообще не представляю.
N>>·>Все ожидают, что 17я версия содержит всё что есть в 8й, значит 17я — потомок 8й. Иными словами, все коммиты в 8й мержатся в 17ю.
N>>Нет, может быть много специфики, которая в 17-й просто нафиг не нужна (например, подсистема переделана и проблемы нет уже в принципе).
·>Тогда будет пустой мерж. В графе истории зафиксируется явная запись о том, что "подсистема переделана, проблема больше не актуальна". Вместо "а хз, вася вроде смотрел год назад, и вроде бы что-то пофиксил в каком-то из бранчей, надо бы в почте покопаться...".

Ну а так эта история присутствует в тикете. Чем это хуже чем держать её в репе?
Всё равно будут смотреть в тикете в первую очередь.

Здравствуйте, netch80, Вы писали:

N>>>Не получится замержить, код сильно разный.
N>·>_Если_ будет конфликт — зарезолвим. В этом и суть мержей — сливать разный код и разрешать конфликты если сильно разный.
N>Для настоящего мержа нужна общая база истории, причём честная. И зачем её тут такую поддерживать?
База для 17й версии — это 8я версия. Надо просто поддерживать историю в порядке, чтобы она не разъезжалась, тогда всё просто мержится с минимумом конфликтов.

N>>>А могли начать фиксить в 8-й и черипиками доползти вверх до 17-й. Разницы по сути никакой.
N>·>Разница в графе истории. Так у тебя две навечно разъехавшиеся ветки, сравнить которые нет никакой возможности. А если в графе настоящие мержи, то всё как на ладони.
N>Зачем их вообще _так_ сравнивать?
Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф. Если там бардак, притом искусственно созданный, то он бесполезный и приходится полагаться на комменты в системе тикетов, и прочие мамойклянусы.

N>>>·>Все ожидают, что 17я версия содержит всё что есть в 8й, значит 17я — потомок 8й. Иными словами, все коммиты в 8й мержатся в 17ю.
N>>>Нет, может быть много специфики, которая в 17-й просто нафиг не нужна (например, подсистема переделана и проблемы нет уже в принципе).
N>·>Тогда будет пустой мерж. В графе истории зафиксируется явная запись о том, что "подсистема переделана, проблема больше не актуальна". Вместо "а хз, вася вроде смотрел год назад, и вроде бы что-то пофиксил в каком-то из бранчей, надо бы в почте покопаться...".
N>Ну а так эта история присутствует в тикете. Чем это хуже чем держать её в репе?
Гы. Зачем вообще что-то держать в репе?! Забэкапил исходники rar-кой и готово.

N>Всё равно будут смотреть в тикете в первую очередь.
А по уму тикет должен апдейтиться по содержимому истории, ибо она первична, т.к. клиентам ты отправляешь код из скв, а не тикеты.

Здравствуйте, ·, Вы писали:

N>>>>Не получится замержить, код сильно разный.
N>>·>_Если_ будет конфликт — зарезолвим. В этом и суть мержей — сливать разный код и разрешать конфликты если сильно разный.
N>>Для настоящего мержа нужна общая база истории, причём честная. И зачем её тут такую поддерживать?
·>База для 17й версии — это 8я версия.

Скажи это Полу Викси

Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.

·> Надо просто поддерживать историю в порядке, чтобы она не разъезжалась, тогда всё просто мержится с минимумом конфликтов.

Расшифруй "разъежалась".

N>>>>А могли начать фиксить в 8-й и черипиками доползти вверх до 17-й. Разницы по сути никакой.
N>>·>Разница в графе истории. Так у тебя две навечно разъехавшиеся ветки, сравнить которые нет никакой возможности. А если в графе настоящие мержи, то всё как на ладони.
N>>Зачем их вообще _так_ сравнивать?
·>Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф.

Он и отображает. Безо всякого форсирования на возможность мержа заметно разных веток.

N>>Ну а так эта история присутствует в тикете. Чем это хуже чем держать её в репе?
·>Гы. Зачем вообще что-то держать в репе?! Забэкапил исходники rar-кой и готово.

Не утрируй.

N>>Всё равно будут смотреть в тикете в первую очередь.
·>А по уму тикет должен апдейтиться по содержимому истории, ибо она первична, т.к. клиентам ты отправляешь код из скв, а не тикеты.

Нет, первичны как раз цели и задачи. Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
Клиентам отправляется продукт, а не "код из СКВ".

Здравствуйте, vsb, Вы писали:

vsb>Линейная история. История всегда линейна, никаких циклов в этом графе нет. При разработке ветки с новой фичей периодически делается rebase на main (или на test, если у вас отдельная ветка для разработки), ну или хотя бы перед тем, как отдать фичу на code review или слияние.

Я считаю это просто проблема инструментов Git, в том же Mercurial есть прекрасный TortoiseHG и выразительный язык запросов позволяющие легко понять в какой ветке был коммит.

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

Случай 1:
Работаем через GitHub и его систему ревью кода и хотим в большинстве случаев 1 коммит на 1 PR.
В этом случае каждый rebase убивает комментарии и потом становится сложно понять починен ли комментарий или нет.
То есть тупо надо смотреть всё с нуля и это практически каждый раз.
Тут у нас есть решение в виде простых коммитов в нашу ветку и в случае надобности слияния из базовой ветки.
А далее одной кнопка в GitHub squash+merge (раздавить + сливаться ) получаем 1 коммит как и хотели.
Таким образом получаем все плюсы и ни одного минуса.

Случай 2:
Работаем через GitHub и его систему ревью кода и хотим более одного коммита на 1 PR.
В этом случае мы работаем также через слияние, чтобы комментарии не терялись.
А далее после одобрения переписываем историю так как мы хотели бы её видеть в логе, перед этим синхронизируемся с базовой веткой.
Потом мы добавляем коммиты через rebase для того чтобы добавить историю как мы задумывали.
Получаем нужный нам лог и не создаём себе проблем в процессе рвеью.

Это был пример GitHub, возможно другие системы могут нормально работать с изменённой историей или не давать более одного коммита на PR.

Здравствуйте, netch80, Вы писали:

N>·>База для 17й версии — это 8я версия.
N>Скажи это Полу Викси
Не знаком я с этим товарищем.

N>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
Шо? Не понял. Когда писали 8ю версию, она была транком. В общем я ничего не понял кто там на ком стоит. Нарисуй граф что-ли.

N>·> Надо просто поддерживать историю в порядке, чтобы она не разъезжалась, тогда всё просто мержится с минимумом конфликтов.
N>Расшифруй "разъежалась".
diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.

N>>>Зачем их вообще _так_ сравнивать?
N>·>Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф.
N>Он и отображает. Безо всякого форсирования на возможность мержа заметно разных веток.
Нет. Замерженный коммит появляется в обоих ветках. Зачерипиканный — это два независимых коммита с т.з. графа истории.

N>>>Ну а так эта история присутствует в тикете. Чем это хуже чем держать её в репе?
N>·>Гы. Зачем вообще что-то держать в репе?! Забэкапил исходники rar-кой и готово.
N>Не утрируй.
Я намекаю. Если ты не используешь эту фичу, это не значит, что она какая-то неправильная и вообще ненужная. Ты попробуй начать использовать и некоторые вещи могут упроститься.

N>>>Всё равно будут смотреть в тикете в первую очередь.
N>·>А по уму тикет должен апдейтиться по содержимому истории, ибо она первична, т.к. клиентам ты отправляешь код из скв, а не тикеты.
N>Нет, первичны как раз цели и задачи.
Не утрируй. Я говорю с т.з. разработки. А то заяви уж сразу — первична прибыль, и перейдём сразу к обсуждению бизнес-планов...

N>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
N>Клиентам отправляется продукт, а не "код из СКВ".
Продукт-то из чего собирается? Из тикетов?

Здравствуйте, ·, Вы писали:

N>>·>База для 17й версии — это 8я версия.
N>>Скажи это Полу Викси
·>Не знаком я с этим товарищем.

Ну тогда просто знай, что переход BIND 8 -> 9 был сделан через написание кода с нуля. Вся старая история не была продолжена.

За это его, да, ругали, но сейчас версий раньше 9-х нет.

N>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
·>Шо? Не понял. Когда писали 8ю версию, она была транком.

Когда вводили принципиально новое — да. Когда релизили и патчили — уже нет.

N>>·> Надо просто поддерживать историю в порядке, чтобы она не разъезжалась, тогда всё просто мержится с минимумом конфликтов.
N>>Расшифруй "разъежалась".
·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.

Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.

N>>>>Зачем их вообще _так_ сравнивать?
N>>·>Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф.
N>>Он и отображает. Безо всякого форсирования на возможность мержа заметно разных веток.
·>Нет. Замерженный коммит появляется в обоих ветках. Зачерипиканный — это два независимых коммита с т.з. графа истории.

Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.
Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
Ещё работает связь по id тикета, который тоже должен быть в сообщении коммита.
А сложные случаи всё равно требуют анализа задачи.

N>>>>Ну а так эта история присутствует в тикете. Чем это хуже чем держать её в репе?
N>>·>Гы. Зачем вообще что-то держать в репе?! Забэкапил исходники rar-кой и готово.
N>>Не утрируй.
·>Я намекаю. Если ты не используешь эту фичу, это не значит, что она какая-то неправильная и вообще ненужная. Ты попробуй начать использовать и некоторые вещи могут упроститься.

Я знаю этот подход и пробовал его. С ним значительно гиморнее.

N>>>>Всё равно будут смотреть в тикете в первую очередь.
N>>·>А по уму тикет должен апдейтиться по содержимому истории, ибо она первична, т.к. клиентам ты отправляешь код из скв, а не тикеты.
N>>Нет, первичны как раз цели и задачи.
·>Не утрируй. Я говорю с т.з. разработки. А то заяви уж сразу — первична прибыль, и перейдём сразу к обсуждению бизнес-планов...

N>>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
N>>Клиентам отправляется продукт, а не "код из СКВ".
·>Продукт-то из чего собирается? Из тикетов?

И на что тут влияет, из чего собирается продукт?

Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.

Здравствуйте, netch80, Вы писали:

N>·>Не знаком я с этим товарищем.
N>Ну тогда просто знай, что переход BIND 8 -> 9 был сделан через написание кода с нуля. Вся старая история не была продолжена.
Бывает. Такая ситуация будет отражена в графе истории, что истории независимы и у них нет общей базы. Но причём обсуждаемый тут cherry-pick vs merge? Поможет ли gerrit? Или ты просто за жизнь рассуждаешь?

N>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
N>·>Шо? Не понял. Когда писали 8ю версию, она была транком.
N>Когда вводили принципиально новое — да. Когда релизили и патчили — уже нет.
Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.

N>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.
N>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...

N>>>·>Для удобства. Если граф истории отражает реальный процесс разработки — это хороший граф.
N>>>Он и отображает. Безо всякого форсирования на возможность мержа заметно разных веток.
N>·>Нет. Замерженный коммит появляется в обоих ветках. Зачерипиканный — это два независимых коммита с т.з. графа истории.
N>Правильно, поэтому это надо решать принципиально иначе. Вон Gerrit ведёт отдельный change-id, который отличается от commit id, и который, в отличие от commit id, сохраняется при черипиках, при ребейзинге, при format-apply, и служит более надёжным идентификатором.
Да. Мне тоже подход gerrit нравится. Но это всё-таки заточено на PR процесс, а не на мерж между разными ветками.

N>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
В gerrit это и делают — хуком генерят дополнительный uuid в коммит.

N>Ещё работает связь по id тикета, который тоже должен быть в сообщении коммита.
N>А сложные случаи всё равно требуют анализа задачи.
Во-во.

N>>>Не утрируй.
N>·>Я намекаю. Если ты не используешь эту фичу, это не значит, что она какая-то неправильная и вообще ненужная. Ты попробуй начать использовать и некоторые вещи могут упроститься.
N>Я знаю этот подход и пробовал его. С ним значительно гиморнее.
А в чём гемморой проявлялся?

N>>>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
N>>>Клиентам отправляется продукт, а не "код из СКВ".
N>·>Продукт-то из чего собирается? Из тикетов?
N>И на что тут влияет, из чего собирается продукт?
С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.

N>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
Можно какие-нибудь детали? Пример?

Здравствуйте, netch80, Вы писали:

N>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.

В чем проблема сделать на транке?

Здравствуйте, vsb, Вы писали:

vsb>Спагетти. Каждое изменение вносится в исходную ветку через merge. При визуализации разобраться в этом решительно невозможно.

Глупое беспочвенное заявление. Что именно "невозможно"? Не умеешь посмотреть, что сделано в каждой ветке? Тогда что ты делаешь вообще в ИТ?

Здравствуйте, Sharov, Вы писали:

N>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.

S>В чем проблема сделать на транке?

В том, что результат практически гарантированно получится глючным.
Есть базовое противоречие: надо больше новых фич (в общем смысле, может быть и удаление чего-то), чтобы держать конкурентоспособность — и надо меньше новых фич, чтобы доводить до ума стабильный (малоизменяемый) код. Когда идёт активная разработка новых фич, обязательно что-то не учтут.
ТРИЗ учит, что такое противоречие может быть разрешено во времени или в пространстве (или в обоих). В случае софта в пространстве это значит разные ветки разработки.
Поэтому что бы ни происходило в транке — для релиза отделяется релизная ветка, запрещаются новые фичи в ней, и начинается период стабилизации уже установленного набора фич. В наших терминах это переход из зелёной зоны в жёлтую. В транке всегда зелёная и там продолжают разработку, периодически ломая всё и тут же восстанавливая.
Стабилизация длится около фиксированного времени, но до признания ветки рабочей. После жёлтой зоны ещё идёт красная (допускаются только критические или секьюрити фиксы). И уже из этого результат релизится.
Это универсальный метод, который используется в 100500 мест. Названия могут быть другими — например code freeze вместо красной зоны и code slush вместо жёлтой.
Существование отдельных фиче-веток не влияет на эту схему.
Да, есть те, где "с колёс в бой", но и то там часто просто более короткие релизные ветки. Всякие фейсбуки, где скорость выкатывания фич важнее качества функциональности, а юзерам всё равно пофиг, сколько котиков показано, я не считаю — это особый мир, который мне неинтересен.

Здравствуйте, ·, Вы писали:

N>>·>Не знаком я с этим товарищем.
N>>Ну тогда просто знай, что переход BIND 8 -> 9 был сделан через написание кода с нуля. Вся старая история не была продолжена.
·>Бывает. Такая ситуация будет отражена в графе истории, что истории независимы и у них нет общей базы. Но причём обсуждаемый тут cherry-pick vs merge? Поможет ли gerrit? Или ты просто за жизнь рассуждаешь?

Ты абсолютизировал тут связь в истории, я привёл контрпример.
И вот он как раз в пользу подхода стиля cherry-pick (если не вообще format-patch + am): если нет общего базового коммита, git на попытку merge тупо сходит с ума, предлагая обе версии каждого файла с нуля.
Я с таким однажды возился, и таки пришлось каждый переносимый патч применять через am. (Cherry-pick не проходил тоже, а то было бы проще, но это потому, что поциэнт даже концы строк не нормализовал.)

N>>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
N>>·>Шо? Не понял. Когда писали 8ю версию, она была транком.
N>>Когда вводили принципиально новое — да. Когда релизили и патчили — уже нет.
·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.

"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?

N>>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.
N>>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...

При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
rerere не приходилось использовать. Возможно, он и тут помог бы.

·>Да. Мне тоже подход gerrit нравится. Но это всё-таки заточено на PR процесс, а не на мерж между разными ветками.

Что такое "PR процесс", я не понял. Если разработку согласно тикетам, то да, где-то на это. Мерж между ветками — я писал рядом — там возможен, но обычно нафиг не нужен. Из всех команд его использовала только одна, с самым специфичным компонентом.

N>>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
·>В gerrit это и делают — хуком генерят дополнительный uuid в коммит.

Ну, я имел в виду что это не то, что обычно называется UUID или GUID, хотя выполняет по сути ту же роль.

N>>Ещё работает связь по id тикета, который тоже должен быть в сообщении коммита.
N>>А сложные случаи всё равно требуют анализа задачи.
·>Во-во.

Да, но не кода напрямую. Код только отражение спецификации, а одна и та же функция в коде может решать множество разных задач. Или не решать.

·>А в чём гемморой проявлялся?

См. ниже.

N>>>>Из них делаются спецификации, из них тикеты с задачами и только из них — код. Он тут вообще "четвертичен", если не дальше.
N>>>>Клиентам отправляется продукт, а не "код из СКВ".
N>>·>Продукт-то из чего собирается? Из тикетов?
N>>И на что тут влияет, из чего собирается продукт?
·>С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.

Мне и большинству моих коллег — разбираться в графе коммитов не проще. Часто, наоборот, сложнее. А "всё что пихается" это как раз про код 15-летней давности.

N>>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
·>Можно какие-нибудь детали? Пример?

Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
С черипиками такого нет — приходит уже код достаточно свежего вида, а связь пусть даже с древнейшими багами обеспечивается за счёт других идентификаторов.

Здравствуйте, netch80, Вы писали:

N>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
S>>В чем проблема сделать на транке?
N>В том, что результат практически гарантированно получится глючным.
Ты по-моему всё перепутал. В момент создании 8й версии, 17й ещё и в планах не было, поэтому ветка 8го релиза была создана на транке (а больше и неоткуда). Мой тезис заключается в том, что все последующие изменения 8го релиза должны мержиться обратно и в транк, и в поздние поддерживаемые релизы. Ты можешь черрипикать, с т.з. кода результат будет такой же, но ты теряешь на поддержке автоматизации мержей, т.к. git теряет связность в графе истории.
Вот тут на картинке. Мне свою картинку рисовать лень, тут куча лишнего, поэтому только смотри на develop и release branches. Зелёные точки Bugfixes мержатся в желтые:

Здравствуйте, ·, Вы писали:

N>>>>Но даже если без такого радикализма, 8-я версия, очень вероятно, будет сделана на релизной ветке, а не на транке (вообще не представляю себе, кто будет её делать на транке). И там может быть всё заметно иначе.
S>>>В чем проблема сделать на транке?
N>>В том, что результат практически гарантированно получится глючным.
·>Ты по-моему всё перепутал. В момент создании 8й версии, 17й ещё и в планах не было, поэтому ветка 8го релиза была создана на транке (а больше и неоткуда).

Следи за формулировками:
ты: "ветка 8го релиза была создана на транке"
я: "8-я версия... (вообще не представляю себе, кто будет её делать на транке)"
Sharov на это: "В чем проблема сделать на транке?"

Вариант, когда релиз создаётся на релизной ветке (уже неважно, от чего она была форкнута, может, вообще с нуля влили), тебя устраивает. Непонятно, о чём возражаешь.

·> Мой тезис заключается в том, что все последующие изменения 8го релиза должны мержиться обратно и в транк, и в поздние поддерживаемые релизы. Ты можешь черрипикать, с т.з. кода результат будет такой же, но ты теряешь на поддержке автоматизации мержей, т.к. git теряет связность в графе истории.

Ну вот я и не вижу ничего ценного в этой "автоматизации мержей", зато вижу недостатки и следующий из него гимор.

·>Вот тут на картинке. Мне свою картинку рисовать лень, тут куча лишнего, поэтому только смотри на develop и release branches.

Спасибо, идейно я и без этой картинки понимал подход. Повторюсь, люди из соседней команды так делали со своим компонентом. Никому больше не понравилось и их подход не повторили.

Здравствуйте, netch80, Вы писали:

N>·>Бывает. Такая ситуация будет отражена в графе истории, что истории независимы и у них нет общей базы. Но причём обсуждаемый тут cherry-pick vs merge? Поможет ли gerrit? Или ты просто за жизнь рассуждаешь?
N>Ты абсолютизировал тут связь в истории, я привёл контрпример.
N>И вот он как раз в пользу подхода стиля cherry-pick (если не вообще format-patch + am): если нет общего базового коммита, git на попытку merge тупо сходит с ума, предлагая обе версии каждого файла с нуля.
N>Я с таким однажды возился, и таки пришлось каждый переносимый патч применять через am. (Cherry-pick не проходил тоже, а то было бы проще, но это потому, что поциэнт даже концы строк не нормализовал.)
Да я знаю. Но я не говорю о универсальном всемогутере. Если с проектом беда и бардак, то нужно выбирать способ более топорный и требующий больше возни. Но по умолчанию нужно делать как проще, а не в гамаке и стоя.

N>·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.
N>"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
N>У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?
Самый простой путь — начать вносить багфикс в самую поддерживаемую раннюю версию и потом мержить в следующие по возрастанию. Можно всё черрипикать, но тогда ты просто идёшь более сложным путём и создаёшь себе проблемы на пустом месте.

N>>>·>diverged branch. Если в 17 всегда мержить 8, то 17 не будет diverged от 8 и мержи упрощаются.
N>>>Нет, не упрощаются. Часть правок от 8 не нужна, часть слишком сложно мержить из-за изменения стиля, расположения по файлам и всё такое, часть реализуется совсем иначе.
N>·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...
N>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
Хз, не уверен... но у меня сложилось впечатление, что при черрипиках нетривиальных конфликтов больше. Плюс черрипики это каджый коммит индивидуально, тогда как мерж — это сразу пачка, одно действие, один раунд разрешения конфликтов.
Плюс всякие запросы типа git log v1.2.3..v2.3.4 выдают меньше треша. Плюс bisect не спотыкается на лишних коммитах. И т.п.

N>·>Да. Мне тоже подход gerrit нравится. Но это всё-таки заточено на PR процесс, а не на мерж между разными ветками.
N>Что такое "PR процесс", я не понял. Если разработку согласно тикетам, то да, где-то на это. Мерж между ветками — я писал рядом — там возможен, но обычно нафиг не нужен. Из всех команд его использовала только одна, с самым специфичным компонентом.
peer review.

N>>>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
N>·>В gerrit это и делают — хуком генерят дополнительный uuid в коммит.
N>Ну, я имел в виду что это не то, что обычно называется UUID или GUID, хотя выполняет по сути ту же роль.
sha1 коммита вроде ничем от guid не отличается... (ну кроме формата)

N>·>С т.з. разработчика — результат работы — коммиты. И разбираться в графе истории проще, чем в тикетах, особенно если о виде графа заботятся, а не пихают всё что пихается.
N>Мне и большинству моих коллег — разбираться в графе коммитов не проще. Часто, наоборот, сложнее. А "всё что пихается" это как раз про код 15-летней давности.
Я этот процесс в jenkins pipeline присобачил. При сборке очередного фикса в релизной ветке, вначале происходит мерж в develop. И проблем с мержами/черрипикингом у нас просто не стало.

N>>>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
N>·>Можно какие-нибудь детали? Пример?
N>Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
Когда я прикручивал этот pipeline я почистил эти конюшни, но благо у нас код не такой старый, несложно было.

N>С черипиками такого нет — приходит уже код достаточно свежего вида, а связь пусть даже с древнейшими багами обеспечивается за счёт других идентификаторов.
Ну да... garbage in, garbage out.

Здравствуйте, netch80, Вы писали:

N>·>Ты по-моему всё перепутал. В момент создании 8й версии, 17й ещё и в планах не было, поэтому ветка 8го релиза была создана на транке (а больше и неоткуда).
N>Следи за формулировками:
N>ты: "ветка 8го релиза была создана на транке"
N>я: "8-я версия... (вообще не представляю себе, кто будет её делать на транке)"
N>Sharov на это: "В чем проблема сделать на транке?"
N>Вариант, когда релиз создаётся на релизной ветке (уже неважно, от чего она была форкнута, может, вообще с нуля влили), тебя устраивает. Непонятно, о чём возражаешь.
Я, видимо, не очень улавливаю твою терминологию. Релиз, имхо, всегда создаётся из релизной ветки. Просто по определению... что имеешь в виду ты — мне непонятно.

N>·> Мой тезис заключается в том, что все последующие изменения 8го релиза должны мержиться обратно и в транк, и в поздние поддерживаемые релизы. Ты можешь черрипикать, с т.з. кода результат будет такой же, но ты теряешь на поддержке автоматизации мержей, т.к. git теряет связность в графе истории.
N>Ну вот я и не вижу ничего ценного в этой "автоматизации мержей", зато вижу недостатки и следующий из него гимор.
Если делать так изначально, то нет недостатков, никаких. Недостатки только есть когда у тебя уже есть поломаная рандомными правками история и всё плохо изначально. Вот тут остаётся только два варианта. Продолжать вручную жонглировать cherrypick/apply-patch. Либо потратить время, прочистить хаос и начать делать по-человечески.

N>·>Вот тут на картинке. Мне свою картинку рисовать лень, тут куча лишнего, поэтому только смотри на develop и release branches.
N>Спасибо, идейно я и без этой картинки понимал подход. Повторюсь, люди из соседней команды так делали со своим компонентом. Никому больше не понравилось и их подход не повторили.
А зря. Видимо, поняли только идейно, а технически реализовать просто не получилось.

Здравствуйте, ·, Вы писали:

·>Да я знаю. Но я не говорю о универсальном всемогутере. Если с проектом беда и бардак, то нужно выбирать способ более топорный и требующий больше возни. Но по умолчанию нужно делать как проще, а не в гамаке и стоя.

Ну вот так и делаем. И я фигею от того, что тебе почему-то способ с мержем целой ветки предшествующего релиза легче, чем те же черипики.

N>>·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.
N>>"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
N>>У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?
·>Самый простой путь — начать вносить багфикс в самую поддерживаемую раннюю версию и потом мержить в следующие по возрастанию.

Я не о том. Что ты будешь делать, если тебе нужно собрать релиз из фич, которые просто не соответствуют никакому конкретному известному релизу?

·> Можно всё черрипикать, но тогда ты просто идёшь более сложным путём и создаёшь себе проблемы на пустом месте.

Наоборот, я всё упрощаю.

N>>·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...
N>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
·>Хз, не уверен... но у меня сложилось впечатление, что при черрипиках нетривиальных конфликтов больше. Плюс черрипики это каджый коммит индивидуально, тогда как мерж — это сразу пачка, одно действие, один раунд разрешения конфликтов.

Вот как раз на этом ещё одна проблема мержей — что когда ты заметно разные ветки пытаешься мержить — можешь получить такую кашу, что вообще непонятно, что с ней делать.
rerere, конечно, частично спасает. Но по опыту коллег — далеко не всегда.
Можно решать мержем по одному или несколько коммитов, но тогда разницы с черипиком тупо нет в качестве мержа (зато при черипике не прицепляется чужая неадекватная история).

·>Плюс всякие запросы типа git log v1.2.3..v2.3.4 выдают меньше треша.

Что такое "треш" тут? Ты вместо реальных изменений видишь просто коммит "тут вмержили какую-то фигню"? Причём ты даже не видишь без явного запроса, что именно вмержили?

Это одна из тяжелейших проблем твоего подхода: пусть у тебя в ветке release/8 есть изменения, которые в принципе не предназначены идти в старшие ветки. Ты сказал сидя например в release/9 "git merge release/8". У тебя есть мерж-коммит, поздравляю, но из него теперь надо вычистить всё, что не должно было идти в 9-ю и новее. Например, там какую-то возможность выключили по принципу "оно глючит, мы в 8-й это не включаем". Как ты это будешь делать? Делать реверты всех коммитов, которые не должны были переходить в 9-ю? Ну, успехов в труде.

С черипиками те изменения, которые надо переносить, чётко определены и переносятся именно они.

·> Плюс bisect не спотыкается на лишних коммитах. И т.п.

bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.

N>>>>Можно было вместо этого просто генерировать uuid на коммит, но их метод чуть надёжнее.
N>>·>В gerrit это и делают — хуком генерят дополнительный uuid в коммит.
N>>Ну, я имел в виду что это не то, что обычно называется UUID или GUID, хотя выполняет по сути ту же роль.
·>sha1 коммита вроде ничем от guid не отличается... (ну кроме формата)

Он длиннее 160 бит вместо 128 (из которых в лучшем случае 122 меняются).

N>>>>Я ничего не утрирую, всё на опыте. Вариант с мержем из предыдущих веток приводит к резкому усложнению сопровождения кода. В истории тупо мусор.
N>>·>Можно какие-нибудь детали? Пример?
N>>Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
·>Когда я прикручивал этот pipeline я почистил эти конюшни, но благо у нас код не такой старый, несложно было.

Ты в принципе не можешь почистить, если какие-то компоненты переписываются с нуля, какие-то принципиально реструктурируются. Хотя если у тебя в репе такого не происходит... слегка завидую, но это неинтересные тепличные условия.

Здравствуйте, ·, Вы писали:

·>Я, видимо, не очень улавливаю твою терминологию. Релиз, имхо, всегда создаётся из релизной ветки. Просто по определению... что имеешь в виду ты — мне непонятно.

Подождём тогда Sharov с уточнением, что он имел в виду.

N>>·>Вот тут на картинке. Мне свою картинку рисовать лень, тут куча лишнего, поэтому только смотри на develop и release branches.
N>>Спасибо, идейно я и без этой картинки понимал подход. Повторюсь, люди из соседней команды так делали со своим компонентом. Никому больше не понравилось и их подход не повторили.
·>А зря. Видимо, поняли только идейно, а технически реализовать просто не получилось.

Ну вот у тебя какие-то явно сверхтепличные условия, что это могло работать.

Здравствуйте, netch80, Вы писали:

N>·>Да я знаю. Но я не говорю о универсальном всемогутере. Если с проектом беда и бардак, то нужно выбирать способ более топорный и требующий больше возни. Но по умолчанию нужно делать как проще, а не в гамаке и стоя.
N>Ну вот так и делаем. И я фигею от того, что тебе почему-то способ с мержем целой ветки предшествующего релиза легче, чем те же черипики.
Как правило, все изменения в релизе надо мержить в последний код, притом сразу. Иначе бага поправленная в версии 8 возникнет снова при апргейде на 9ю. Клиентам такое, обычно, не нравится, мягко говоря.

N>>>·>Если патчили изначально бардаком, накатывая разные изменения в разные точки истории, то да — в хаосе не разобраться. С черрипиками будет вообще беда.
N>>>"В разные точки" это насколько разные? В >99% случаев, когда обнаруживается баг, определяется сразу, в какие ветки вносить его правку, и после одобрения это происходит одновременно со всеми целевыми ветками. В этом случае бардак минимизирован до следовых количеств.
N>>>У тебя есть какой-то типовой сценарий, когда надо собирать отдельный релиз из кучи правок вразнос? Так бывает?
N>·>Самый простой путь — начать вносить багфикс в самую поддерживаемую раннюю версию и потом мержить в следующие по возрастанию.
N>Я не о том. Что ты будешь делать, если тебе нужно собрать релиз из фич, которые просто не соответствуют никакому конкретному известному релизу?
Не надо так делать. Или я не очень понимаю зачем так вообще делать? Собирать какую-то уникально неповторимую версию, с которой невозможно без седых волос проапгедиться ни на какую другую, т.к. неизвестно чем одна сборная солянка отличается от другой.
Но если очень хочется в гамаке собрать определённую солянку, то да, черрипикаешь, называешь как-нибудь с префиксом 8.2.3-weirdlyPatched и никогда никуда не мержишь.

N>·> Можно всё черрипикать, но тогда ты просто идёшь более сложным путём и создаёшь себе проблемы на пустом месте.
N>Наоборот, я всё упрощаю.
Ты создаёшь множество snowflake версий. С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.

N>>>·>Ну и? Чем поможет cherry-pick? Вот merge помочь может — git может детектить перемещение расположения по файлам. А если ещё и rerere включить...
N>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>·>Хз, не уверен... но у меня сложилось впечатление, что при черрипиках нетривиальных конфликтов больше. Плюс черрипики это каджый коммит индивидуально, тогда как мерж — это сразу пачка, одно действие, один раунд разрешения конфликтов.
N>Вот как раз на этом ещё одна проблема мержей — что когда ты заметно разные ветки пытаешься мержить — можешь получить такую кашу, что вообще непонятно, что с ней делать.
А просто не надо создавать заметно разные версии. Версии должны не diverge в разные стороны, а старые версии должны быть behind новых. Не даром же их циферками нумеруют, подразумевают ЧУМ.

N>rerere, конечно, частично спасает. Но по опыту коллег — далеко не всегда.
N>Можно решать мержем по одному или несколько коммитов, но тогда разницы с черипиком тупо нет в качестве мержа (зато при черипике не прицепляется чужая неадекватная история).
Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.

N>·>Плюс всякие запросы типа git log v1.2.3..v2.3.4 выдают меньше треша.
N>Что такое "треш" тут? Ты вместо реальных изменений видишь просто коммит "тут вмержили какую-то фигню"? Причём ты даже не видишь без явного запроса, что именно вмержили?
Мерж коммиты можно просто игнорировать. Даже ключик есть специальный --no-merges.

N>Это одна из тяжелейших проблем твоего подхода: пусть у тебя в ветке release/8 есть изменения, которые в принципе не предназначены идти в старшие ветки.
merge --strategy ours и всё: явно прописали в истории, что эти изменения не предназначены идти в старшие версии.

N>Ты сказал сидя например в release/9 "git merge release/8". У тебя есть мерж-коммит, поздравляю, но из него теперь надо вычистить всё, что не должно было идти в 9-ю и новее.
N>Например, там какую-то возможность выключили по принципу "оно глючит, мы в 8-й это не включаем". Как ты это будешь делать? Делать реверты всех коммитов, которые не должны были переходить в 9-ю? Ну, успехов в труде.
Да. Не вижу проблемы. Ты просто предполагаешь, что у тебя версии 8 и 9 изначально разъехались на километры и в репе хаос. Так просто не надо делать и хаоса не будет. Изначально 8 просто предок 9й. Как только добавили фикс в 8ю, мержим его в 9ю. Используя ours если мы заранее знаем, что не хотим этот конкретный фикс в 9й или revert впоследствии, если выясним это позже.

N>С черипиками те изменения, которые надо переносить, чётко определены и переносятся именно они.
И получаете хаос со снежинками.

N>·> Плюс bisect не спотыкается на лишних коммитах. И т.п.
N>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.

N>·>sha1 коммита вроде ничем от guid не отличается... (ну кроме формата)
N>Он длиннее 160 бит вместо 128 (из которых в лучшем случае 122 меняются).
Ну да. И на что это влияет?

N>>>Открытого примера у меня нет, а основная проблема в том, когда начинаешь смотреть, что это смержено, и оказывается, что попадаешь на неактуальную фигню 15-летней давности и приходится регулярно отвлекаться, чтобы потом откидывать её.
N>·>Когда я прикручивал этот pipeline я почистил эти конюшни, но благо у нас код не такой старый, несложно было.
N>Ты в принципе не можешь почистить, если какие-то компоненты переписываются с нуля, какие-то принципиально реструктурируются. Хотя если у тебя в репе такого не происходит... слегка завидую, но это неинтересные тепличные условия.
strategy ours

Здравствуйте, netch80, Вы писали:

N>·>А зря. Видимо, поняли только идейно, а технически реализовать просто не получилось.
N>Ну вот у тебя какие-то явно сверхтепличные условия, что это могло работать.
Такие условия можно создать.