I have been reading a bit more about trunk based development, my company currently mainly uses the git flow model, and I had a question regarding the commits that happen on the trunk and how they are versioned.I'll use the Paul Hammant blog post to try and keep the question less subjective. So below we have the branching model from his blog postI'm interested in what 'version' each of the green commits generates from the trunk. Exampleafter the cherry pick to generate 1.1.1 there are about 15 commits on trunk before we branch the 1.2.X version. Each time those commits go on to the trunk I am assuming the trunk is built and unit tested (maybe even goes to a staging environment) so what version are those commits? Does it matter?TC picks up one of the commits and builds the projects and unit tests. Does it generate an artifact? I'm wondering about how you would then deploy it via Chef or similar to the staging environment if that is indeed what you do with trunk based dev like this.I'm guessing in environments were there are dozens of changes every day the versioning must either be automated (a semantic delta added by way of the commit message) or not seen as very important due to the high volume and flux of changes.
How to version when using trunk based development
version control;versioning;release management;semantic versioning