@Revertron у проекта может быть несколько параллельных, но вполне "релизных" веток. Так бывает, когда продукт делается под разных заказчиков, например.

Есть, условный, мейн лайн, а остальные строятся поверх. При этом легко может быть, что ошибка исправлена только для Х, а потом её тащат в мейнлайн, чтобы другие получили фикс. А может быть и так, что сначала делается фикс для Х, потом для Y, потому что он следующим пойдёт в релиз, потом для Z, а потом только в мейн лайн

@medvedych ты описываешь сценарий, когда есть 1 продукт и он собирается из мастера или, например, от мастера делается бранч релиза, а после релиза этот бранч льётся в мастер.

Я про ситуацию, когда у тебя на одном мастере 15 бранчей и все релизные, просто под разных заказчиков. Все релизятся в свои сроки, т.к. заказчикам нужно в разное время. У каждого есть какая-то специфичная фича, а некоторые специфичны для некоторых, но не для всех.

@ever это понятно. Искать присутствие могу и `git log --oneline | grep <sha256>`, например. А бранчи: `git branch --contains=<sha256>`.

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