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

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

Вот именно что "как правило". Главное, что исключения надо потом специально обходить.

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

Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.

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

Не понимаю этого термина.

·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.

1. Джиру в топку, если там сложно копаться.
2. В чём копаться-то? Есть метаданные тикета и есть указание релизов, в которые попали правки из него.

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

На практике так не бывает. Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.

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

Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.

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

Ну тогда ты не увидишь, что в них собственно изменилось. Это ещё хуже — без такого ключа хотя бы есть намёк, что надо что-то уточнять.

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

И так на каждое изменение. То есть тебе нужно что-то изменив в 8-й тут же примержить это в 9-ю формально, но за счёт ours реально ничего не мержить. И не забыть это сделать, потому что если не сделать, то потом оно взорвётся на следующем реальном мерже, где не будет никакого ours.
Тебе не кажется, что ты сам себя регулярно сажаешь на зажжённую пороховую бочку?

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

Нет, всё просто и понятно, и без сидения на горящем порохе.

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

Да, выглядит. Нет, спотыкаться не на чем.

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

Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.