В Git есть два основных подхода к разработке:

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

Большой плюс в том, что когда смотришь на историю main, то всё очень просто и понятно. Также удобно смотреть pull request-ы по коммитам.

У этого подхода я вижу два минуса:

1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос. Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).

2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.

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

Плюсы/минусы аналогичны минусам/плюсам выше.

Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.

Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?

vsb>1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос.
Не коммить в чужие ветки. Работаете над одной фичей — сделайте бранч для фичи и каждому разработчику отдельный бранч.

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

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

vsb>У этого подхода я вижу два минуса:
vsb>1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос. Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).
Это хорошо работает в условиях короткоживущих веток. Если у тебя ветки маленькие, два-три коммита, живут два-три дня, то хаосу возникнуть в общем-то негде.
Если ветка большая, то ребейз лучше оставить на потом. Т.е. вначале толпой долго пилили, допилили, решили, что готово к мержу — договариваетесь, делаете ребейз, ещё раз всё проверяете каждый коммит и мержите.

vsb>2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
В IDEA сделали отличный UI для rebase.

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

vsb>Плюсы/минусы аналогичны минусам/плюсам выше.
vsb>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Как минимум, наличие довольно мощных rebase-команд в стандартной поставке самого git говорит об обратном.

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
В своих ветках ребейзю по полной, в том числе reword/fixup/squash/etc, каждый коммит стараюсь причесать. Если с кем-то работаю над некой веткой, то договариваюсь о стратегии с участниками.

vsb:

vsb>В Git есть два основных подхода к разработке:
vsb>Линейная история. История всегда линейна, никаких циклов в этом графе нет.
В гите орграф и так без циклов. Насколько помню, разветвление и слияние в орграфах называется "гамак".

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

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?

У нас trunck-based подход, т.е. через rebase, с отдельной веткой для каждой фичи. Да, если над фичей будет работать несколько человек, они рано или поздно что-то перетрут. При этом, если над фичей вынужденны работать несколько человек, значит была не верная декомпозиция задачи и фича слишком большая.

В целом я согласен, этот подход менее очевиден и несколько более сложен. Но это окупается за счёт получения простой и однозначной истории коммитов в мастере. Да и графический интерфейс ГитХаб(Лаб) частично компенсирует недостатки этого подхода, т.к. последнее слияние фича_ветка -> мастер делается не руками, а сервером Гит.

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

vsb>>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами.
M>Нигде не встречал работу в мастер-бранчем через постоянные merge. Только PR + squash and merge.

PR+squash -- это типа склеить все коммиты в один? Т.е. merge будет из одного коммита? Почему не rebase тогда?

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

vsb>>2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
·>В IDEA сделали отличный UI для rebase.

Я tortoise git(обновил до последней) регулярно путаюсь в rebase... На сколько там понятен merge, настолько непонятен
rebase...

S>PR+squash -- это типа склеить все коммиты в один? Т.е. merge будет из одного коммита?
Да

S>Почему не rebase тогда?
Rebase фича ветки делается перед PR.

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

S>Я tortoise git(обновил до последней) регулярно путаюсь в rebase... На сколько там понятен merge, настолько непонятен
S>rebase...

Я очень рекомендую прочитать Merging vs. Rebasing, в крайнем случае именно благодаря этой статье у меня в голове окончательно картинка сложилась.

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

Случайно увидел при подборе монитора

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

vsb>Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).

Git ничего не теряет. До сборки мусора можно посмотреть и восстановить любую версию. См. команду show-ref.

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

vsb>>Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).

DR>Git ничего не теряет. До сборки мусора можно посмотреть и восстановить любую версию. См. команду show-ref.

Ну в теории да, но это уже больше похоже на восстановление удалённого с диска файла.

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

vsb>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Кстати. Если подумать, то мерж по большому счёту немного про другое. Это когда у тебя сложный продукт со множеством поддерживаемых версий. Т.е. обнаружили багу в JDK, выяснили, что она тянется аж с java8. Пофиксили в java8, а потом это всё замержили и в java11, 17 и master.
А типичный проект с одной веткой и release-тегами... там rebase — то что доктор прописал.

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

vsb>>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
·>Кстати. Если подумать, то мерж по большому счёту немного про другое. Это когда у тебя сложный продукт со множеством поддерживаемых версий. Т.е. обнаружили багу в JDK, выяснили, что она тянется аж с java8. Пофиксили в java8, а потом это всё замержили и в java11, 17 и master.

На мой взгляд это через cherry picking правильней делается. А куда тут мердж засунуть, я вообще не представляю.

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

vsb>1. rebase требует force push. Если зачем-то над этой веткой кто-то ещё работал, возникает хаос.
В случае с "кем-то ещё" есть git push --force-with-lease, более безопасный чем git push --force. Ну и к тому же, git fetch -p @{U} и там уже смотреть что делать с изменениями с удалённого репозитория (иногда эти изменения -- твои).

vsb>Также теряются исходные коммиты, если при rebase была сделана ошибка, то её уже не исправить. Частично решается созданием новой ветки при каждом rebase-е, но тогда в репозитории будет множество веток, которые надо не забыть подчищать (и не перепутать при подчистке).
Нет, есть git reflog, умеет отмирать со временем сам, или принудительно -- с помощью git gc. Вот что в git не залетает в историю, так это индекс, который можно случайно грохнуть git reset --hard.

vsb>если при rebase была сделана ошибка, то её уже не исправить
Если имеется в виду исправление сложных наборов патчей на своей ветке при интерактивном варианте, то тогда да, соглашусь: после git rebase --continue подправить патч можно будет только в следующей сессии интерактивного git rebase. Вроде, это можно частично решить с помощью git rerere, но не уверен.

vsb>2. rebase это сложно для понимания и применения, UI при rebase менее очевидный, при разрешении конфликтов разработчик не видит своих будущих изменений.
vsb>rebase это сложно для понимания
Нет, совершенно. Это просто git reset на определённый коммит и git cherry-pick на стероидах.
vsb>rebase это сложно для ... применения
В некоторых случаях -- может быть. Например, если на topic-ветке затеяли рефакторинг, то тогда, скорее всего, придётся подчищать каждый коммит. Или, например, если от topic-ветки растут ещё ветки. Тогда приходится делать git rebase для каждой ветки отдельно в правильном порядке, так как git совершенно безразлично что на что перебазировать. Я когда-то писал для этого скрипты, умеющие такой rebase автоматизировать, но чем меньше сущностей -- тем проще + не нужно тянуть за собой свой набор скриптов на каждую машину.
vsb>при разрешении конфликтов разработчик не видит своих будущих изменений
Смотря куда смотрит. Для этого есть как минимум git log --left-right @{U}...{U} (с троеточием), и добавление маркеров в commit message (если на проекте есть такое соглашение), и git trailers, и настройка $PS1 в bash (у меня, например, всегда видно количество изменений локально и с удалённого репозитория, если topic-ветка и её upstream-ветка указывают на разные фиксации). И это только перед началом rebase. Во время самого git rebase возможны другие техники.

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
* внедрение изменений с родительской ветки на topic-ветку — git rebase локально.
* внедрение изменений с topic-ветки на родительскую — git merge --no-ff --no-squash (локально или удалённо, зависит от того, как в неё принимаются изменения) после предварительного git rebase topic-ветки.

vsb>Также у меня есть такое ощущение, что Git в целом больше заточен именно на подход с merge-ами. Это не технический аргумент, но я никогда не любил идти "против течения" и использовать инструмент не так, как его проектируют.
Мне кажется, что git вообще ни на что не был изначально заточен. Это действительно stupid content tracker. Вот Mercurial заточен на merge, там rebase не привествуется вообще, и, если не ошибаюсь, по умолчанию даже не доступен, и позже пресекается public-фазами коммитов.

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

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

vsb>А куда тут мердж засунуть, я вообще не представляю.
Все ожидают, что 17я версия содержит всё что есть в 8й, значит 17я — потомок 8й. Иными словами, все коммиты в 8й мержатся в 17ю.

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

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

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

vsb>>На мой взгляд это через cherry picking правильней делается.
·>Нет, конечно.

Да, конечно.

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

А могли начать фиксить в 8-й и черипиками доползти вверх до 17-й. Разницы по сути никакой.

vsb>>А куда тут мердж засунуть, я вообще не представляю.
·>Все ожидают, что 17я версия содержит всё что есть в 8й, значит 17я — потомок 8й. Иными словами, все коммиты в 8й мержатся в 17ю.

Нет, может быть много специфики, которая в 17-й просто нафиг не нужна (например, подсистема переделана и проблемы нет уже в принципе).

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

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

vsb>Случайно увидел при подборе монитора

Нормально. У нас до 6 видимых таким образом веток дорастало без проблем и заметных последствий.

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

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-й просто нафиг не нужна (например, подсистема переделана и проблемы нет уже в принципе).
Тогда будет пустой мерж. В графе истории зафиксируется явная запись о том, что "подсистема переделана, проблема больше не актуальна". Вместо "а хз, вася вроде смотрел год назад, и вроде бы что-то пофиксил в каком-то из бранчей, надо бы в почте покопаться...".

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

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?

Оба варианта абсолютизируют крайние формы. Неумеренность тут вредна.

Действительно, линейная история удобнее тем, что на каждом мерже
1) Понятно, откуда пришло изменение: сам мерж может в принципе содержать нечто, чего не было исходно ни в одном родителе;
2) Родительские коммиты, корректные по отдельности, могут конфликтовать. Об этом часто забывают, не проверяя результаты мержа.
Результаты мержа должны проверяться — через CI в идеале на каждый коммит, или хотя бы регулярно с адекватной частотой (типа, раз в сутки).

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

Но требование тотальной линеаризации плохо, с другой стороны, тем, что вызывает много конфликтов там, где их в принципе не может быть (разные люди пилят разные неперекающиеся части — ну например одна команда оптимизирует SQL индексы, другая чинит JSON схемы. Зачем их форсировать делать что-то по порядку и подгоняться под чужое?

На прошлой работе это выглядело так:

1. Сервер — Gerrit — умеет удобно работать с цепочками коммитов и с их версиями (можно переделывать по многу раз и сравнивать версии диффами), и допускать только по прохождению peer review и одобрения от CI.

Он не рассчитан на git-flow (не разрешает просто так делать 100500 частных веток), но позволяет делать неименованные (нумерованные) ветки конкретных подцепочек коммитов (1 или больше).

Нормальный вариант процесса это несколько попыток выставить на ревью до получения финального одобрения.

2. У большинства реп выставлен режим: сервер делает мержи, но не принимает их от юзеров. (Можно было бы и принимать, но проще так.)
Сервер, если видит контекстный конфликт, отказывает в мерже, тогда надо делать rebase.
Рекомендуется линеаризовать по максимуму.
Мержи могут давать проблемные версии. Лечится это своевременным обнаружением (CI запуски по крону), ручной проверкой, когда надо, и замораживанием изменений в релизных ветках.

Особая проблема тут, когда подходит день замораживания рабочей ветки и отщепления релизной, все стараются в пятницу свалить свои коммиты

3. У некоторых с особо сложными, но нечастыми отдельными изменениями — всё наоборот: запрещены мержи самим сервером, но разрешено принимать их от юзеров.
Вот они умудряются делать мержи между релизными ветками.

По-моему, это был очень симпатичный вариант как организовывать совместную работу.

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>Ну вот у тебя какие-то явно сверхтепличные условия, что это могло работать.
Такие условия можно создать.

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

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

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

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

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

N>>>Я не о том. Что ты будешь делать, если тебе нужно собрать релиз из фич, которые просто не соответствуют никакому конкретному известному релизу?
N>·>Не надо так делать. Или я не очень понимаю зачем так вообще делать? Собирать какую-то уникально неповторимую версию, с которой невозможно без седых волос проапгедиться ни на какую другую, т.к. неизвестно чем одна сборная солянка отличается от другой.
N>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
Не понимаю что значит "зафиксировать как ветку".
Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
Вот правильно поставленный процесс мержей это обеспечивает. А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.

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

N>·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.
N>1. Джиру в топку, если там сложно копаться.
Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.

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

N>>>Вот как раз на этом ещё одна проблема мержей — что когда ты заметно разные ветки пытаешься мержить — можешь получить такую кашу, что вообще непонятно, что с ней делать.
N>·>А просто не надо создавать заметно разные версии. Версии должны не diverge в разные стороны, а старые версии должны быть behind новых. Не даром же их циферками нумеруют, подразумевают ЧУМ.
N>На практике так не бывает.
Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.
Подход с черрипиками это то что творилось во всяких svn.
Вот тут от автора: cherry-pick shouldn't be *common*. А у тебя оно основная часть твоих процессов.

N>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
"чуть по разному" на языке git означает conflict resolution и мерж записывает в историю это соответствующим образом. cherry-pick с конфликтом это тупо отдельный коммит, никак не связанный с существующим, даже patch-id будет другим, что ломает алгоритмы conflict resolution.

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

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

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

N>Тебе не кажется, что ты сам себя регулярно сажаешь на зажжённую пороховую бочку?
Я не сажаю, ещё чего. jenkins pipeline этим занимается.

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

N>·>strategy ours
N>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
Чё? Это стратегия мержа.

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

N>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.

"Учу читать. Дорого."
Я писал, почему там нет "старых багов". Повторяться не хочу.

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

Создать ветку с адаптацией под конкретного кастомера.

·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
·>Вот правильно поставленный процесс мержей это обеспечивает.

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

·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.

А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
Нифига себе у тебя искусственный интеллект завёлся.

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

Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.

N>>·> С парой каждых надо внимательно разбираться копаясь в комментах джиры что где есть, а чего нет.
N>>1. Джиру в топку, если там сложно копаться.
·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.

Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.

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

Организацией процесса разработки. "Мамойклянусь" это у тебя с "замержим, чтобы не глёбнуло потом".

·>Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.

Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
Вот раз, вот два черипики, а вот оригинал. Заметь, commit id оригинала (то есть окончательно принятый в транк) попал в сообщение коммита в черипиках, то есть они были сделаны уже после высочайшего одобрения.

·>Подход с черрипиками это то что творилось во всяких svn.
·>Вот тут от автора: cherry-pick shouldn't be *common*.

А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.

·> А у тебя оно основная часть твоих процессов.

Да. Точно так же как сейчас в linux kernel за пределами транка.

N>>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
·>"чуть по разному" на языке git означает conflict resolution

Язык git тут ни при чём. Например, v8 делает настройку бриджа через ebtables, а v9 — через nftables. Или в v8 обмен данными на своей оболочке вокруг старого AJAX, а v9 — через React.
Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.

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

Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?

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

OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.

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

Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?

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

Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.

N>>·>strategy ours
N>>Мерж, который не мерж, только для того, чтобы потом не взрываться. Шарман, девочки.
·>Чё? Это стратегия мержа.

Дадада. Вот и получается формально мерж, по факту не мерж.

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

N>>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
N>·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.
N>"Учу читать. Дорого."
N>Я писал, почему там нет "старых багов". Повторяться не хочу.
Я знаю, что можно таки добиться и делать без старых багов стоя в гамаке. Но это не самый простой способ.

N>>>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
N>·>Не понимаю что значит "зафиксировать как ветку".
N>Создать ветку с адаптацией под конкретного кастомера.
Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?

N>·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
N>·>Вот правильно поставленный процесс мержей это обеспечивает.
N>Нет, не обеспечивает. Описанные тобой меры работают только в простейших случаях.
Просто не надо усложнять случаи. Тогда они и будут простейшие. kernel.git внезапно простейший случай.

N>Но это не главное тут:
N>·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.
N>А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
N>Нифига себе у тебя искусственный интеллект завёлся.
Да. У меня пайплайн мержит автоматом, я же уже писал. Когда автомат не смог сработать из-за конфликта, надо мержить вручную. Это происходит редко. Я точно не считал, но по ощущениям не более чем в 5 изменений из ста.
Притом ручной мерж обычно тривиальный, т.к. он делается самим же разработчиком в тот же момент когда он запушил изменение. Он знает что и как, о чём изменение, и быстро понимает как разрешать конфликт.
Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.

N>·>Уникальные, друг на друга непохожие в мелких деталях, трудно сравнить две, слишком много различий.
N>Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.
"ветку с адаптацией под конкретного кастомера" — это оно и есть.

N>>>1. Джиру в топку, если там сложно копаться.
N>·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.
N>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).

N>·>Это как раз то, на что был заточен git. Вот тут сплошные мержи из тагов (т.е. релизов). Попробуй найди черрипик.
N>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
N>Вот раз, вот два черипики, а вот оригинал. Заметь, commit id оригинала (то есть окончательно принятый в транк) попал в сообщение коммита в черипиках, то есть они были сделаны уже после высочайшего одобрения.
Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.

N>·>Подход с черрипиками это то что творилось во всяких svn.
N>·>Вот тут от автора: cherry-pick shouldn't be *common*.
N>А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.
Читал я, конечно. В данном случае он говорит о So the kinds of merges I *really* dislike are the ones that are basically "let's do a regular merge every day to keep up-to-date. Мы обсуждаем мержи из релизов, вот он пишет: merge with mainline at major releases. А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?

N>>>Разные версии чуть по-разному развиваются. Одна и та же функциональность как для юзера может быть реализована разным кодом в разных местах.
N>·>"чуть по разному" на языке git означает conflict resolution
N>Язык git тут ни при чём. Например, v8 делает настройку бриджа через ebtables, а v9 — через nftables. Или в v8 обмен данными на своей оболочке вокруг старого AJAX, а v9 — через React.
N>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.

N>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]

N>·>Так ничего не изменилось. Замержилось же. Ты нарисуй на бумажке граф версий и разберись какие коммиты выбираются по v1.2.3..v2.3.4.
N>OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.
Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.

N>>>·>merge --strategy ours и всё: явно прописали в истории, что эти изменения не предназначены идти в старшие версии.
N>>>И так на каждое изменение. То есть тебе нужно что-то изменив в 8-й тут же примержить это в 9-ю формально, но за счёт ours реально ничего не мержить. И не забыть это сделать, потому что если не сделать, то потом оно взорвётся на следующем реальном мерже, где не будет никакого ours.
N>·>Ты вроде и так заявил "черипик делается именно сразу же". В чём разница-то? "ours" же это редкое исключение которое надо "обходить".
N>Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
N>Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?
Делать что в параллель? Мержить 8->9 одновременно? Ничего не будет. Кто первый запушит, того и тапки. У второго будет пустой noop-мерж в худшем случае.
Все эти недостатки возникают в том или ином виде и с черрипиком.

N>>>>>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
N>>>·>Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.
N>>>Да, выглядит. Нет, спотыкаться не на чем.
N>·>Одно изменение — дважды, притом чуть по-разному, если были конфликты.
N>Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.
Это как? Замерженное повторно не мержится. Будет "already up-to-date".

N>·>Чё? Это стратегия мержа.
N>Дадада. Вот и получается формально мерж, по факту не мерж.
Не знаю что за факт такой.

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

N>Это универсальный метод, который используется в 100500 мест. Названия могут быть другими — например code freeze вместо красной зоны и code slush вместо жёлтой.
N>Существование отдельных фиче-веток не влияет на эту схему.

А где про это можно попкорнее прочитать?

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

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

А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

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

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

Я ничего такого не имел в виду -- было утв. про транк, дескать из него релиз не собирается.
Я спросил почему нет.

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

N>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not

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

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

S>А есть сейчас какие-то аналоги gerrit'у для CR? Я с ним не работал, имеет смысл поизучать?

github, bitbucket и прочие — можно комментировать, можно ставить "согласен" / "не согласен", можно подключать CI.
gitlab, думаю, точно так же (не щупал ни разу).

Главное — есть заметные отличия в стиле. Gerrit не даёт возможность (или это неудобно) массово плодить всякие _именованные_ персональные фичеветки. Удобно работать с ограниченным набором целевых веток (у нас был master, а робот форкал от него всякие release90, release91...)
Временные ветки на предложения есть, но имени у них нет (можно поставить тег, но тег не уникален), только номер; получается, например, цепочка из ревью 123000, 123003, 123004... каждое надо рассмотреть и одобрить или отказать. Если все одобрены — можно отправить (какое-то ревью и всех его родителей) в целевую ветку, по их родителю видна эта ветка (соответственно master, release90 и так далее).
Зато он умеет, например, такое: сделал цепочку из 10 коммитов, в первом был заведен класс Foo. Пришёл главный ревьюер, сказал — нет, это должно быть Moo. Переименовал во всех коммитах, теперь у каждого из ревью есть patchset 1 и patchset 2. Их можно сравнить друг с другом, оно показывает даже разными цветами правки самого патчсета и правки, пришедшие из разных родителей (красный/зелёный и синий/жёлтый соответственно).
Вот тут, например, можно потыкать на публичном проекте (удобный пример, 10 выкатываний правки и цепочка коммитов это солидная история).

У github, bitbucket и прочих нет раздельного одобрямса на каждый коммит, хотя есть комментарии по строкам. Зато у них плоди именованные ветки сколько угодно, главное, не забывать их потом зачищать

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

N>>>>Вот именно что "как правило". Главное, что исключения надо потом специально обходить.
N>>·>Не знаю как у вас, но обычно принято не кормить клиентов старыми багами.
N>>"Учу читать. Дорого."
N>>Я писал, почему там нет "старых багов". Повторяться не хочу.

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

Если дифф правки переносится 1:1 — всё просто и проще чем с мержем вверх.
Если нет, то в любом случае надо думать, как переносить исправление.

N>>>>Если зафиксировать как ветку, то проблем сильно меньше. Кстати, именно тут и можно мержить — проблем с этим меньше.
N>>·>Не понимаю что значит "зафиксировать как ветку".
N>>Создать ветку с адаптацией под конкретного кастомера.
·>Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?

Это долго описывать, но вкратце:
1. Большинство таки сидят на стандартных ветках.
2. Если кастомер хочет какие-то особые правки себе лично, то или он сам об этом заботится (локальные патчи и сборка своими силами), или договаривается о поддержании с нашей стороны (считаем, доплачивает, но не всегда напрямую). В любом из этих двух вариантов забота мейнтейнера этих правок, что именно ему надо делать. Часто оказывается, что проблема решается в новой версии другим методом и ему уже не нужен отдельный патч на это.

N>>·>Проблема не в том, что как где зафиксировать, что бы это ни значило, а в семантике нумерации версий. Если я, как пользователь, пользуюсь версией 1.2.3 и решил проапгрейдиться до 2.3.4, то я хочу быть уверенным, что у меня не вылезет тот же баг, который пофиксили в 1.2.1. Т.е., всё что было сделано в релизе 1.* должно работать в 2.*.
N>>·>Вот правильно поставленный процесс мержей это обеспечивает.
N>>Нет, не обеспечивает. Описанные тобой меры работают только в простейших случаях.
·>Просто не надо усложнять случаи. Тогда они и будут простейшие. kernel.git внезапно простейший случай.

Ты уводишь разговор куда-то в сторону.

N>>Но это не главное тут:
N>>·> А черри-пикинг — всё приходится делать вручную, приходится каким-то другим способом вести учёт.
N>>А мержить, значит, у тебя автомат настроили. Тогда кто этому автомату объясняет, что мержить в реале, а что только формально (ours)? А конфликты тоже автомат решает?
N>>Нифига себе у тебя искусственный интеллект завёлся.
·>Да. У меня пайплайн мержит автоматом, я же уже писал.

Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.

·>Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
·>С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.

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

N>>·>Уникальные, друг на друга непохожие в мелких деталях, трудно сравнить две, слишком много различий.
N>>Нет, не создаю. И не понимаю, чем моё описание могло вызвать такие фантазии.
·>"ветку с адаптацией под конкретного кастомера" — это оно и есть.

Нет там "слишком много различий". Опять ты что-то прифантазировал с потолка.

N>>>>1. Джиру в топку, если там сложно копаться.
N>>·>Да неважно. Любую трекинговую систему или что там у вас. История кода должна храниться в графе истории, для этого предназначенным, а не где-то в стороне.
N>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).

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

N>>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
·>Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.

Про "редки" твоя фантазия. Посмотри эти истории внимательно: для стабильных веток таких коммитов большинство.
Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).

N>>А полностью прочитать сообщение не хочешь? Или это уже пошла фигурная резьба по квотингу? Весь контекст определяет только транковую разработку. И к тому же там объясняется, почему у него "the reason I ask people to not do lots of merges", что совсем не в пользу твоих подходов.
·>Читал я, конечно. В данном случае он говорит о So the kinds of merges I *really* dislike are the ones that are basically "let's do a regular merge every day to keep up-to-date. Мы обсуждаем мержи из релизов, вот он пишет: merge with mainline at major releases.

И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).

·> А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?

Скорее да, если я правильно понял, о чём ты.
В момент старта подготовки, например, 90-го релиза создаётся соответствующая ветка (пусть она и называется release-90). Транк продолжает дальше расти. Если фикс бага делается на транке, ему делается ЧП в release-90, из неё в release-89 и так далее (пока не останавливаемся на ветке, развитие которой уже остановлено). На каждый момент можно сходить на внутреннюю страничку и узнать, какие релизы в каком состоянии (жёлтая зона — разработчик сам решает, уместно ли исправление, по функциональности, красная зона — надо обсуждать с QA, нет в списке — самому ничего не делать).
Можно и в обратном направлении (типа 89->90->транк) или из средней точки, но 1) надо это явно объяснять, 2) вызывает вопросы "почему так?"
В любом случае результат будет проверен собственными тестами и потом QA отделом.

N>>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
·>И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.

ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.

N>>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
·>Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]

Ты кое-где порядок перепутал
А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода. Даже в исконной обители git черипики — постоянная практика.

N>>·>Так ничего не изменилось. Замержилось же. Ты нарисуй на бумажке граф версий и разберись какие коммиты выбираются по v1.2.3..v2.3.4.
N>>OK, понял. В моём варианте такой запрос лога просто не выполнится — нет прямого пути между этими версиями. Этот путь — артефакт твоего подхода и имеет смысл только в его рамках.
·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.

Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.

N>>Разница в том, что черипик это явное действие: его надо сделать, чтобы получить результат. Контроль прямой и явный — не сделал, сразу видно.
N>>Фиктивный мерж твоего стиля это действие, которое если не сделать, то взорвётся не сразу, а потом. Факт пропуска не очевиден, требуются специальные костыли, чтобы его обеспечивать. Мало того, этот подход ещё и не защищён от обгонов — что будет, если два разработчика начнут делать такое впараллель?
·>Делать что в параллель? Мержить 8->9 одновременно? Ничего не будет. Кто первый запушит, того и тапки. У второго будет пустой noop-мерж в худшем случае.

ну ок.

·>Все эти недостатки возникают в том или ином виде и с черрипиком.

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

N>>>>>>bisect "спотыкается" ровно на том, что нужно. Если что-то сделано в этой ветке, оно и присутствует, причём в предельно явном виде — в виде конкретного коммита, отображённого диффом.
N>>>>·>Каждая черрипикнутая копия коммита для git выгядит как независимый коммит и место где споткнуться.
N>>>>Да, выглядит. Нет, спотыкаться не на чем.
N>>·>Одно изменение — дважды, притом чуть по-разному, если были конфликты.
N>>Это если потом в твоём стиле эти ветки всё-таки замержить между собой. Но вот именно эту глупость и не надо делать.
·>Это как? Замерженное повторно не мержится. Будет "already up-to-date".

Я про то, что конфликты пойдут только если ветки мержить целиком.

N>>·>Чё? Это стратегия мержа.
N>>Дадада. Вот и получается формально мерж, по факту не мерж.
·>Не знаю что за факт такой.

Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.

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

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

N>>Это универсальный метод, который используется в 100500 мест. Названия могут быть другими — например code freeze вместо красной зоны и code slush вместо жёлтой.
N>>Существование отдельных фиче-веток не влияет на эту схему.

S>А где про это можно попкорнее прочитать?

Супернеологизм! Спасибо, запишу.

Подробнее например здесь. В их терминах есть code slush и code freeze.
Схема слегка похожа на нашу, с отличием, что они "примораживают" транк в целом перед тем, как от него форкать релизную ветку, и аналогично ветки старших номеров перед конкретными релизами (как например для 12-й ветки перед форком 12.1, 12.2, 12.3). В это время коммит новых фич недопустим, только правки. Потом они форкают, ветки размораживаются и в них можно постить новое.
У нас такая приморозка не делается, просто по графику форкается релизная ветка (старшая или младшая) и на неё назначается полиси.

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

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

N>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not

Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.

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

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

S>Я ничего такого не имел в виду -- было утв. про транк, дескать из него релиз не собирается.
S>Я спросил почему нет.

Можно, не вопрос. Просто менее эффективно для общего процесса, чем из отдельной ветки. Почему — см. предыдущий комментарий.

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

N>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
N>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную. Мержи чаще отрабатывают автоматически, не требуя ручного вмешательства.

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

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

N>>>>При черипике git детектит точно так же. Внутри такой же merge механизм, только источники диффов другие.
N>>·>Ну да, ты не прав, ясен пень. Разница в наличии common ancestor
N>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.

Не вижу причин к подобному выводу. Есть учебный пример?

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

N>>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
N>·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.
N>Не вижу причин к подобному выводу. Есть учебный пример?
Сходи по ссылке, там с подробным описанием как воспроизвести.

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

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

N>>>>·>https://stackoverflow.com/questions/37237637/git-cherry-pick-causes-merge-conflict-while-merging-does-not
N>>>>Нафига мне вообще common ancestor? Ты вообще не понял, о чём я писал.
N>>·>Не тебе, а алгоритму мержа. Суть в том, что при черрипиках конфликтов возникает больше и править надо вручную.
N>>Не вижу причин к подобному выводу. Есть учебный пример?
·>Сходи по ссылке, там с подробным описанием как воспроизвести.

Сходил. Повторил. Ему совершенно правильно объяснили, что он сам дурак.
`git merge other` подтягивает все коммиты 3, 4, 5 одновременно.
В случае ЧП ему надо подтянуть явно все коммиты по очереди, чтобы добиться того же, что при merge. Или, если ему нужен только пятый, да, он должен разобрать конфликт текста.
Но если в случае ЧП он может выделить только 5-й коммит, то при merge у него такой возможности нет.

Ну и что ты пытался показать этим примером, кроме банальной очевидности, что merge не выделяет один коммит из всей ветки?

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

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

N>·>Бедный кастомер. Как он потом с этой ветки будет переходить на другие? Или у вас для каждого кастомера своя личная ветка?
N>Это долго описывать, но вкратце:
N>1. Большинство таки сидят на стандартных ветках.
N>2. Если кастомер хочет какие-то особые правки себе лично, то или он сам об этом заботится (локальные патчи и сборка своими силами), или договаривается о поддержании с нашей стороны (считаем, доплачивает, но не всегда напрямую). В любом из этих двух вариантов забота мейнтейнера этих правок, что именно ему надо делать. Часто оказывается, что проблема решается в новой версии другим методом и ему уже не нужен отдельный патч на это.
Мерж-процесс не запрещает этого. Можно черрипикать для кастомных версий, если очень надо. Но в основном процессе это нафиг не надо и лишний усложнизм.

N>>>Нифига себе у тебя искусственный интеллект завёлся.
N>·>Да. У меня пайплайн мержит автоматом, я же уже писал.
N>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.

N>·>Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
N>·>С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.
N>Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.
Автоматом? Как контролировать что ничего не забыли?

N>>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
N>·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).
N>"Как минимум" там обязательная ссылка на тикет. А в тикете уже всё что нужно включая дискуссии, вики и всё такое.
N>В сообщение коммита добавляется, конечно, описание, почему так, но без совсем уж тотальных подробностей.
Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.

N>>>Разуй глаза и посмотри не только на транковую ветку, а и на то, из чего делаются стабильные ветки ядра (даже если "ванильные").
N>·>Я знаю что их используют. Я говорю о том, что они редки. Их кол-во по сравнению с мержами очень мало: shouldn't be *common*.
N>Про "редки" твоя фантазия. Посмотри эти истории внимательно: для стабильных веток таких коммитов большинство.
Там большинство коммитов — мержи. Черрипики обычно для backporting — когда баг пофикшенный в последней версии очень надо запихать в предыдущую.

N>Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).
Немного покопался и вот тебе ещё типичный пример: один и тот же коммит появляется в jdk-18+33 и в jdk-19+7 и т.д. Вот мерж-коммит из 18+33 в 19. Заметь как там разница merge conflict красиво рисуется. И вообще вся история как на ладони, в трекер лазить не надо.

N>И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).
Ок, соглашусь, тут немного не о том пишут. Поищу на досуге более релевантное. Врочем, я не вижу причин почему эти рекомендации вдруг надо менять на противоположные в немного другом контексте. Рекомендаций к твоему подходу мне видеть пока не доводилось.

N>·> А вот когда он рекомендует черрипикинг: cherry-picking is fine if you do it (a) fairly seldom and (b) just to small patches. Твой пример черрипикнутого коммита оно и есть. В вашем процессе черрипики такие же?
N>Скорее да, если я правильно понял, о чём ты.
Я о том, что черрипикать если и надо, то как можно реже и мелкие однострочные коммиты.

N>В момент старта подготовки, например, 90-го релиза создаётся соответствующая ветка (пусть она и называется release-90). Транк продолжает дальше расти. Если фикс бага делается на транке, ему делается ЧП в release-90, из неё в release-89 и так далее (пока не останавливаемся на ветке, развитие которой уже остановлено). На каждый момент можно сходить на внутреннюю страничку и узнать, какие релизы в каком состоянии (жёлтая зона — разработчик сам решает, уместно ли исправление, по функциональности, красная зона — надо обсуждать с QA, нет в списке — самому ничего не делать).
N>Можно и в обратном направлении (типа 89->90->транк) или из средней точки, но 1) надо это явно объяснять, 2) вызывает вопросы "почему так?"
N>В любом случае результат будет проверен собственными тестами и потом QA отделом.
От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.

N>>>Один и тот же баг может лечиться в них заметно по-разному, мерж средствами git не поможет.
N>·>И? Разве кто-то обязует conflict resolution быть не заметно разным? Мерж поможет зафиксировать знание о том, что баг вылечился, хотя и по-разному и даже можно будет поглядеть в истории в чём эта разница собственно заключается.
N>ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.
Коммит не даёт. Вам даёт знание тикет, если, конечно, его правильно проапдейтили и ничего не перепутали.

N>>>>>·>Мерж по одному-нескольким как раз происходит по ходу пьесы, когда ты работаешь над конкретным изменением, а не через год, когда уже все всё забыли что там такое было и что с этим делать.
N>>>>>Ну так и черипик делается именно сразу же, а не когда забыли, зачем он был нужен.
N>>>·>Тогда это полный бред — зачем черрипикать, если можно замержить?
N>>>Зачем мудохаться с мержем, когда черипик проще, понятнее, контролируемее и надёжнее?
N>·>Напоминает риторические вопросы лет N назад. "Зачем мудохаться с X, когда Y проще, понятнее, контролируемее и надёжнее?", где (X, Y) : [(скв, rar-архивы), (cvs, svn), (svn, git), ...]
N>Ты кое-где порядок перепутал
Ну так ты же мудохаешься с мержами зачем-то. Хинт: мержами пользоваться надо, а не мудохаться с ними.

N>А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода.
А ты меня тут в шарманстве обвиняешь.

N>Даже в исконной обители git черипики — постоянная практика.
Постоянная, но не для того, для чего используете вы. Вы молотком забиваете шурупы. Оно, конечно, лучше, чем гвозди отвёрткой вркучивать, но... И вы даже однажды попробовали плоской отвёрткой закрутить шуруп с крестовой шляпкой, порезались, плюнули и перешли на молоток.

N>·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.
N>Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.
Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.

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

N>·>Это как? Замерженное повторно не мержится. Будет "already up-to-date".
N>Я про то, что конфликты пойдут только если ветки мержить целиком.
Чтобы были конфликты, должны быть незамерженные изменения. А если мы изменения мержим, то и конфликтов не будет.

N>>>Дадада. Вот и получается формально мерж, по факту не мерж.
N>·>Не знаю что за факт такой.
N>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.
Я не знаю что такое фиктивный мерж. Можно сссылку на доки?

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

vsb>>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?
H>* внедрение изменений с родительской ветки на topic-ветку — git rebase локально.
H>* внедрение изменений с topic-ветки на родительскую — git merge --no-ff --no-squash (локально или удалённо, зависит от того, как в неё принимаются изменения) после предварительного git rebase topic-ветки.

Я не могу с topic-ветки на родительскую сделать rebase? git checkout parent, git pull; git checkout topic; git rebase parent
(или как-то так).
Что значит

после предварительного git rebase topic-ветки.

?

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

N>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.

Я что-то упустил, но почему merge с ours фиктивный? Обычный 3-way merge, просто при конфликтах выберут нашу версию.

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

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

N>>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.

S>Я что-то упустил, но почему merge с ours фиктивный? Обычный 3-way merge, просто при конфликтах выберут нашу версию.

Проверил на практике — не совсем.
Вот base: в файле 'a' — 'a', 'b' — 'b'.
Создал ветку 'aa' где в файле 'a' — 'aa'.
Создал ветку 'bb' где в файле 'b' — 'bb'.
Создал ветку 'do_merge' от 'aa' и сказал 'git merge bb'.
Если бы ours работало только при конфликте, то в 'b' было бы 'bb'. Но я вижу там 'b'.
Попробовал ещё и чтобы в ветке bb был файл b1. При таком же мерже — его не оказалось.

Вывод: таки фиктивный.

В доке у него разделяются _strategy_ "ours" и _option_ "ours" для merge strategy. Наверно, ты думал про второе.

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

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

Если это то что ты писал в предыдущем сообщении, то это ерунда

Автор: netch80
Дата: 23.02.22

не имеющая отношения к реальности.

N>>>>Нифига себе у тебя искусственный интеллект завёлся.
N>>·>Да. У меня пайплайн мержит автоматом, я же уже писал.
N>>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
·>Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.

Реверт мержа? Ещё один усложнизм на ровном месте.

N>>·>Про ours я уже объяснял — это вообще редкость (не уверен, что наберётся хоть десяток за год). И решается либо предварительным явным мержем, либо ревертом.
N>>·>С черрипиками беда, что это происходит когда попало и в итоге приходится разрешать конфликты спустя недели, часто кому-то другому, кто не в теме. И не приходится разбираться — незачерипикали что-то нарочно или просто забыли.
N>>Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.
·>Автоматом? Как контролировать что ничего не забыли?

Человеком. Он выбирает, какие коммиты куда должны пойти. Ревьюеры проверяют комплектность со своей точки зрения. Часто оказывается, что для другой ветки что-то надо убрать, что-то добавить.
Финальную точку ставят тесты.
Но сделать ЧП на всю цепочку — для простого случая — это банальное действие.

N>>>>Не должна вся история там храниться. Код — это только код. Множество факторов, например, почему была выбрана такая архитектура и такая реализация, не могут храниться в коде.
N>>·>Может, конечно. Это обычно хранят в комментах коммита (как минимум туда помещают ссылку на вики, например).
N>>"Как минимум" там обязательная ссылка на тикет. А в тикете уже всё что нужно включая дискуссии, вики и всё такое.
N>>В сообщение коммита добавляется, конечно, описание, почему так, но без совсем уж тотальных подробностей.
·>Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.

Спасибо, с практиками знакомы. Но заменять сообщениями коммита всю ту информацию, что может быть в тикете, некорректно — там может быть тонна pdf'ок, логи, и много подобного.
Ты впал в режим Адмирала Ясен Хер и не просто думаешь, что ты главный кэп на форуме, а ещё и активно это пропагандируешь. Это тупо смешно.

·>Там большинство коммитов — мержи. Черрипики обычно для backporting — когда баг пофикшенный в последней версии очень надо запихать в предыдущую.

Именно.

N>>Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).
·>Немного покопался и вот тебе ещё типичный пример: один и тот же коммит появляется в jdk-18+33 и в jdk-19+7 и т.д. Вот мерж-коммит из 18+33 в 19. Заметь как там разница merge conflict красиво рисуется. И вообще вся история как на ладони, в трекер лазить не надо.

OK, есть публичный пример, как люди работают в этой схеме.

N>>И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).
·>Ок, соглашусь, тут немного не о том пишут. Поищу на досуге более релевантное. Врочем, я не вижу причин почему эти рекомендации вдруг надо менять на противоположные в немного другом контексте. Рекомендаций к твоему подходу мне видеть пока не доводилось.

Значит, игнорировал в упор. Потому что их много.

·>От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.

Про мучения ты себе что-то нафантазировал.
Бардак при мержах был бы, если бы мы использовали твой подход с мержами. Но нет такого подхода — нет и бардака

Но я запомню как странный вариант.

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

В коммите есть базовое описание. Если его недостаточно, идём к тикету. Но такие ситуации встречаются уже когда требуется что-то более глубокое, чем просто анализ "когда это возникло", и тогда оно 100% требует анализа контекста, предусловий и т.п.

·>Ну так ты же мудохаешься с мержами зачем-то. Хинт: мержами пользоваться надо, а не мудохаться с ними.

Вот как раз не пользуемся — и поэтому не мудохаемся

N>>А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода.
·>А ты меня тут в шарманстве обвиняешь.

???

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

Плохая аналогия подобна котёнку с дверцей. Ещё и неадекватная.

N>>·>Угу. И так же при твоём варианте лесом пойдёт много вкусностей типа bisect.
N>>Нет, никуда bisect не уходит. Точно так же ЧП коммит будет опознаваем и бисектоспособен в истории.
·>Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.

Не будут. Потому что такого бисекта просто не будет. Он не адекватен и не нужен.

N>>>>Дадада. Вот и получается формально мерж, по факту не мерж.
N>>·>Не знаю что за факт такой.
N>>Ты ж сам через ours делаешь фиктивный мерж — второй родитель есть в истории и игнорируется по факту.
·>Я не знаю что такое фиктивный мерж. Можно сссылку на доки?

Это то, что ты делаешь с ключом ours. Одна сторона формально присутствует, по факту игнорируется.

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

S>Я не могу с topic-ветки на родительскую сделать rebase? git checkout parent, git pull; git checkout topic; git rebase parent
S>(или как-то так).
S>Что значит
S>

S>после предварительного git rebase topic-ветки.

S>?

Почему не можете? Именно так я и делаю, и именно об этом говорил в первом пункте, после чего -- git push --force, конечно. У нас с topic-ветками разрешены любые операции как локально (впрочем, кто запретит-то?), так и удалённо (потому что никто не заморачивается над их защитой). Но запрещено делать слияние в master-ветку без предварительного перебазирования topic-ветки на master (для упрощения будем считать, что единственной родительской веткой является master). Сама механика такой защиты реализуется в git серверными хуками, следуя определёнными правилами, принимающими или отклоняющими измения в ветках (точнее ссылках на фиксации) (правил множество: локально или удалённо пытаются подвинуть ветку; был ли это force-push; пытается ли кто-то откатить её назад; что там с топологией сливаемых изменений и т.д. и т.п., в чём может помочь git merge-base)).

Допустим, у меня локально было так (визуализацию ветки cool-feature для упрощения "согнул" вправо, хотя git log --graph выровняет её и прижмёт к левому краю, но, снова же, это не имеет значения):

  @ "Cool feature change 2" (<- refs/heads/cool-feature; refs/remotes/origin/cool-feature)
  * "Cool feature change 1"
  * "Cool feature change 0"
 /
* (<- refs/heads/master; refs/remotes/origin/master)
|\
| * "Basic feature change"
|/
*

Потом я узнаю, что на master-ветке произошли изменения и они были приняты на master (написали лично, пришло письмо, пропала кнопка "Merge" на том же GitLab). С этого момента, поскольку refs/remotes/origin/cool-feature больше не содержит фиксации, на которую в данный момент указывает refs/heads/master (с точки зрения удалённого репозитория), удалённый репозиторий не позволит принять изменения с ветки cool-feature на master. Локально синхронизируем новые изменения:

$ git checkout master
$ git pull # предпочитаю git fetch --prune && ​git merge --ff-only @{U}

@ "Merge basic-feature-fix into master" (<- refs/heads/master; refs/remotes/origin/master)
|\
| * "Basic feature fix"
|/
| ​@ "Cool feature change 2" (<- refs/heads/cool-feature; refs/remotes/origin/cool-feature)
| ​* "Cool feature change 1"
​| ​* "Cool feature change 0"
​|/
* "Merge basic-feature into master"
|\
| * "Basic feature"
|/
*

Делаем git rebase:

$ git checkout cool-feature
$ git rebase master

  ​@ "Cool feature change 2" (<- refs/heads/cool-feature)
  ​* "Cool feature change 1"
​  ​* "Cool feature change 0"
​ /
@ "Merge basic-feature-fix into master" (<- refs/heads/master; refs/remotes/origin/master)
|\
| * "Basic feature fix"
|/
| @ "Cool feature change 2" (<- refs/remotes/origin/cool-feature)
| ​* "Cool feature change 1"
​| ​* "Cool feature change 0"
​|/
* "Merge basic-feature into master"
|\
| * "Basic feature"
|/
*

Уведомляем удалённый репозиторий о своих изменениях:

$ git push -f

  ​@ "Cool feature change 2" (<- refs/heads/cool-feature; refs/remotes/origin/cool-feature)
  ​* "Cool feature change 1"
​  ​* "Cool feature change 0"
​ /
@ "Merge basic-feature-fix into master" (<- refs/heads/master; refs/remotes/origin/master)
|\
| * "Basic feature fix"
|/
* "Merge basic-feature into master"
|\
| * "Basic feature"
|/
*

После этого снова можем сливать свои изменения на удалённом репозитории, где условный GitLab под капотом у меня делает что-то типа такого:

$ git checkout "$TARGET_REF"
$ git merge --no-ff --no-squash "$SOURCE_REF"
... исполнение проверок в ./git/hooks/pre-merge-commit ...
$ test ! -z "$DELETE_SOURCE_REF" && git branch -d "$SOURCE_REF"

Тогда локально:

$ git checkout master
$ git pull
$ git branch -d cool-feature

@ "Merge cool-feature into master" (<- refs/heads/master; refs/remotes/origin/master)
|\
| ​* "Cool feature change 2" (<- refs/heads/cool-feature) (если ветка на удалённом репозитории не удалена и не было git fetch --prune)
| ​* "Cool feature change 1"
​| ​* "Cool feature change 0"
​|/
* "Merge basic-feature-fix into master"
|\
| * "Basic feature fix"
|/
* "Merge basic-feature into master"
|\
| * "Basic feature"
|/
*

По такой схеме легко увидеть некоторую закономерность. Поэтому:

* --no-ff -- создание отдельной фиксации для слияния ("Merge ... into master"), иначе git на удалённой машине просто переместит refs/heads/master на последнее изменение в cool-feature
__* мотивация 1: упрощение отслеживания времени сливания ветки, иначе имело бы тупо линейный вид как trunk в Subversion;
__* мотивация 2: отчёт лога изменений от версии к версии прямиком из merge-фиксаций с помощью тупого git log --format --merges (но это, к сожалению, если при git merge на удалённом репозитории можно указать свои сообщения)
* контраргумент: "нравится линейность, merge-фиксации засоряют граф" -- можно визуализировать историю с помощью git log --no-merges
* --no-squash -- запретить сжимать все фиксации между master и cool-feature в одно изменение перед слиянием
__* мотивация 1: отслеживание изменений на ветке по отдельности;
__* мотивация 2: возможность git revert отдельного изменения в случае необходимости, если каждая фиксация содержит логически атомарное и завершённое изменение
__* контраргумент: "мне нравится squash, так как он убирает весь промежуточный мусор" -- никто не запрещает регулярно пользоваться commit --amend или интерактивным rebase у себя на ветке по мере необходимости во время рабочего процесса, или позже самому сделать squashed-фиксацию с помощью git rebase -i и команд pick/fixup/squash.

Из минусов такого подхода могу назвать следующее:
* если есть множество открытых PR, каждый из них приходится перебазировать на только что обновлённый master вручную;
* автоматическая генерация сообщений вида "Merge ... into master" на удалённой системе, мягко говоря, малоинформативна, даже если включает в себя ссылки на тикеты в баг-трекерах и на pull-request-ы;
* на удалённом репозитории, если есть CI, это может занимать слишком продолжительное время;
* поскольку rebase это, в общем случае, о применении наборов патчей, со временем неизбежны конфликты с родительских веток в промежуточных изменениях, в то время, как merge просто будет пытаться слить только последние изменения на этих ветках (если не ошиюбаюсь, делая в некоторых случаях исключения) -- это общая проблема rebase, когда его сравнивают с merge; + ещё одна проблема rebase: если при git merge отрезолвили конфликт, при постоянном git rebase изменений, который ещё не слили в родительскую ветку, есть ненулевая возможность неправильно поправить конфликт и даже не заметить этого, что потом можно даже и не вспомнить (но, снова же, по-моему, это решается git rerere);
* иногда на master может попасть что-то нежелательное, что можно удалить только имея права прямой записи в такой master с локальной машины (например, на topic-ветке кто-то сделал commit, а тогда revert (вместо commit --amend, reset, rebase или любого другого способа, убирающего ненужное из истории), таким образом создав zero-diff из двух фиксаций, которые наверняка при review не заметят), при этом предупредив всех, что master придётся подправвить, что может повлиять на уже существующие изменения (как локально, так и удалённо, причём не важно в каком масштабе).

Понимаю, что выложил сумбурно, но как умею, и, надеюсь, это более развёрнуто отвечает на вопрос о применяемых практиках.

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

N>>>Если дифф правки переносится 1:1 — всё просто и проще чем с мержем вверх.
N>>>Если нет, то в любом случае надо думать, как переносить исправление.
N>·>Не проще. И больше шанс нарваться на необходимость ручного разрешения конфликтов.
N>Если это то что ты писал в предыдущем сообщении, то это ерунда

Автор: netch80
Дата: 23.02.22

не имеющая отношения к реальности.
Да, действительно... извиняюсь. Пытаюсь быстренько нагуглить и натыкаюсь не на то. Вот тут есть чтиво про common ancestor и recursive merge: https://devblogs.microsoft.com/oldnewthing/20180315-00/?p=98245

N>>>Такой автомат не умеет решать описанный мной вопрос. Ты опять уводишь в сторону.
N>·>Я вроде ответил. Повторюсь другими словами. По умолчанию автомат мержит. В редких случаях, если заранее известно, что авто-мерж не нужен, то мержим желаемым образом вручную и тогда автомат ничего не делает, т.к. ветки не будут diverged, мержить банально нечего. В очень редких случаях, если выяснилось, что мерж не нужен был, можно сделать реверт.
N>Реверт мержа? Ещё один усложнизм на ровном месте.
Эээ? Что в этом сложного? Одна команда, не сложнее черрипика. А с учётом того, что на автоматизация заменяет сотни ручных черрипиков то один-два реверта ну никак на усложним не тянут. Или ты тоже панически боишься ревертов?

N>>>Вот именно что "когда попало" не происходит. Черипики во все активные ветки, куда нужно переправлять патч, посылаются сразу при исполнении тикета. Ты себе что-то такое непонятное прифантазировал про нас и делаешь из этого кривые выводы.
N>·>Автоматом? Как контролировать что ничего не забыли?
N>Человеком. Он выбирает, какие коммиты куда должны пойти. Ревьюеры проверяют комплектность со своей точки зрения. Часто оказывается, что для другой ветки что-то надо убрать, что-то добавить.
N>Финальную точку ставят тесты.
N>Но сделать ЧП на всю цепочку — для простого случая — это банальное действие.
Т.е. контроля нет. Вся надежда на внимательность человека.

N>·>Т.е. таки _могут_ храниться в коде. Погугли "git message best practices" или типа того. То что вы не храните — это ваша проблема.
N>Спасибо, с практиками знакомы. Но заменять сообщениями коммита всю ту информацию, что может быть в тикете, некорректно — там может быть тонна pdf'ок, логи, и много подобного.
N>Ты впал в режим Адмирала Ясен Хер и не просто думаешь, что ты главный кэп на форуме, а ещё и активно это пропагандируешь. Это тупо смешно.
Ты заявил глупую вещь, что "не могут храниться в коде", вот и пришлось покапинанствовать. Более того, при желании pdf-и и логи тоже можно класть в репу в виде git notes.

N>·>Там большинство коммитов — мержи. Черрипики обычно для backporting — когда баг пофикшенный в последней версии очень надо запихать в предыдущую.
N>Именно.
backporting — обычно происходит редко, и индикация бардака в проекте. А я гововрю о forward-porting, это идеал процесса разработки.

N>>>Ну а для транка я никогда такой подход и не предлагал. (Хотя иногда используем ЧП в направлении более свежих веток; нетипично, но допустимо).
N>·>Немного покопался и вот тебе ещё типичный пример: один и тот же коммит появляется в jdk-18+33 и в jdk-19+7 и т.д. Вот мерж-коммит из 18+33 в 19. Заметь как там разница merge conflict красиво рисуется. И вообще вся история как на ладони, в трекер лазить не надо.
N>OK, есть публичный пример, как люди работают в этой схеме.
Это не некий пример, мне лень искать, но полагаю большинство современных проектов идут по такой системе. Это то на что заточен git и прочие тулзы около него. Например, в том же github ты видишь список тегов и веток в которых лежит данный коммит, чп эту систему ломают.
Твоя система — это устаревший подход из всяких svn, которые мержить не умели.

N>>>И всё равно это контекст транка: например, на нём сформировали и тегировали 5.10, вот в этот момент всем, кто ведёт разработку в доп. ветках, предлагают сделать merge (или rebase).
N>·>Ок, соглашусь, тут немного не о том пишут. Поищу на досуге более релевантное. Врочем, я не вижу причин почему эти рекомендации вдруг надо менять на противоположные в немного другом контексте. Рекомендаций к твоему подходу мне видеть пока не доводилось.
N>Значит, игнорировал в упор. Потому что их много.
Ссылку в студию.

N>·>От младших к старшим — это и есть естественное направление, DAG однако. У вас всё перевёрнуто, отсюда и мучения с черрипиками и бардак при мержах.
N>Про мучения ты себе что-то нафантазировал.
N>Бардак при мержах был бы, если бы мы использовали твой подход с мержами. Но нет такого подхода — нет и бардака
Ага. В мелком тривиальном проекте типа jdk оно может и сработает, а в вашем исключительном проекте другие законы природы.

N>Но я запомню как странный вариант.
Да, запомните этот твит!

N>>>ЧП даёт то же знание, что баг вылечился. Коммит с тегом тикета есть в истории, тикет содержит ссылки на исправленные ветки. Ещё и в сообщении коммита могут быть нужные слова.
N>·>Коммит не даёт. Вам даёт знание тикет, если, конечно, его правильно проапдейтили и ничего не перепутали.
N>В коммите есть базовое описание. Если его недостаточно, идём к тикету. Но такие ситуации встречаются уже когда требуется что-то более глубокое, чем просто анализ "когда это возникло", и тогда оно 100% требует анализа контекста, предусловий и т.п.
Я не про описание коммита, а про положение коммита в графе истории.

N>·>Ну так ты же мудохаешься с мержами зачем-то. Хинт: мержами пользоваться надо, а не мудохаться с ними.
N>Вот как раз не пользуемся — и поэтому не мудохаемся
Вы мудохаетесь с чп.

N>>>А так — мало ли что напоминает. Обвинить в ретроградстве тривиально, сложнее — доказать обвинение. Пока что у тебя не получается: ни достаточных аргументов, ни массового опыта такого подхода.
N>·>А ты меня тут в шарманстве обвиняешь.
N>???
Ну что-то про девочки-шарман высказался по поводу каких-то "необычных" мержей.

N>>>Даже в исконной обители git черипики — постоянная практика.
N>·>Постоянная, но не для того, для чего используете вы. Вы молотком забиваете шурупы. Оно, конечно, лучше, чем гвозди отвёрткой вркучивать, но... И вы даже однажды попробовали плоской отвёрткой закрутить шуруп с крестовой шляпкой, порезались, плюнули и перешли на молоток.
N>Плохая аналогия подобна котёнку с дверцей. Ещё и неадекватная.
Что за котёнок — я не знаю. А моя аналогия очень точная. Использование черрипиков для forwardporting — типичное забивание шурупов молотком.

N>·>Ты не понял. Баги пофиксенные в v1 не должны появляться при бисекте v1.2.3..v2.3.4, а черрипики будут.
N>Не будут. Потому что такого бисекта просто не будет. Он не адекватен и не нужен.
Почему? Это какой-то закон природы? Чем ваш релиз 89 с десятком патчей так принципиально полностью отличается от релиза 90 с патчами? Неужели вы проект уже 90 раз с нуля переписывали?!!

N>·>Я не знаю что такое фиктивный мерж. Можно сссылку на доки?
N>Это то, что ты делаешь с ключом ours. Одна сторона формально присутствует, по факту игнорируется.
Я не знаю что это значит. Ну допустим ты наклеил ярлык "фиктивный". И? Ты говоришь как будто это что-то плохое.

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

h> $ git pull # предпочитаю git fetch --prune && ​git merge --ff-only @{U}
Можно просто git pull --ff-only или config pull.ff=only и будет по дефолту.

h> Делаем git rebase:
h> $ git checkout master
h> $ git pull
h> $ git checkout cool-feature
h> $ git rebase master

Не обязательно так сложно, просто сразу уже находясь в "cool-feature" сделать git pull -r origin master.

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

vsb>Каким подходом вы пользуетесь, как решаете проблемы (и считаете ли их проблемами)?

Мержи с причесанными сообщениями (не полностью автоматическими, а подправленными ручками). Потому что в этом случае есть выбор, какую историю смотреть. Можно смотреть весь граф если очень хочется. Можно смотреть только мастер и там будут красивые одиночные merge requests с прекрасным описанием. Мелкие проблемы с незнанием ключиков вроде --first-parent (и log, и bisect его поддерживают, что еще надо то?) решаются обучением.