> One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag the

> One way in which it is useful, is that you can tag your build artifacts (like docker images) with the commit id in the development branch, and just re-tag them when you want to promote the artifact to main or production, or whatever. I don't understand what you're talking about. The development build artifacts are useless afterwards, you can't "promote" an artifact from development to main without rebuilding unless you're basically the only person working on it, as the integrated behaviour (and thus the corresponding artifacts) can differ from the pre-integration ones. The only situation where you could reuse the development artifacts as-is with no risk is if the branch is fast-forwardable. Which the integration could just take in account by not rebasing branches which are already rebased. > potentially producing an entirely different artifact which might differ from the one you just tested and validated on your development branch. You need one anyway, even if the development branch validates it still has to be validated post-integration as it may fail at that point. > [1] Unless you back-fill that information after merge, but the workflow is getting really convoluted at this point. Is it? All of it is easily automatable. Why are you limiting yourself for things the computer takes care of?