Hi Jimmy,

To answer your question, yes! We use a trunk-based gitflow pattern and do not desire long-running git branches, based on the versions. Mainly since tags are read-only while a branch could be updated and we want to ensure at all costs that a dbt transformation, that is being pointed to, cannot be updated unless through our automated process (will detail below). While we can use branch protections and the like, we would rather have a continual release process that creates tags for our dbt repositories and utilize the releases function for release notes, documentation, etc. It would be onerous to automate the Github release and then after create a branch based off the tag, etc. Not impossible, but just not ideal, especially when the tag is all that we really need.

As for automation through the Fivetran API, we have a lot of integrations with the API to do operations and status checks, along with automated provisioning of connectors, destinations, and such. We continue to update our functionality as we build our solutions. Part of that would be upon a successful release to the `main` branch of the dbt repositories, we would schedule the transformations to be updated to the latest release (or a configured release version should it be necessary) as part of a continual deployment pipeline, but staggered across our transformations so that we can rollout releases slowly per destination. 

In summary, the tag being a read-only version is key. We know it's doable in other ways, but based on the Fivetran implementation, adding in the ability to specify a branch or a tag doesn't seem like a very large lift considering. 

Thanks for consideration and hopefully this can be done!