Git branching strategy for TYPO3 projects

I've been working with git and TYPO3 CMS for several years and seen different approaches on how to work with git in TYPO3 projects. I found that both trunk-based workflows and git-flow do not match the daily reality in a typical TYPO3 website projects, where the agency develops the website for a certain customer.

Trunk based workflows only have one long living branch, the trunk or main branch, meaning all feature branches are merged into the main branch after beeing completed. Git-flow is a lot closer to reality having both master and develop as long living branches, where master is production-ready at any time and develop contains all the features and is used for creating a new release.

There is still one peace missing in git-flow. A preview branch containing the most recent code for customer review without the need to take all of it into production. I've often experience customers requesting 2 new features, which take a few coding, testing, customer review and fixes. During the development of the 2 new features, the customers requests 3 small bugfixes which should be deployed in production as soon as possible, after beeing reviewed, of course.

This is were I introduced a small change to the git-flow model. The develop branch is called staging or preview to reflect its purpose. This branch still contains the newest changes and is automatically deployed to the staging environment for customer review. The feature branch remains until the feature is tested and approved by the customer. When this happens, the feature branch is merged into the main branch. New feature branches are not branched from the develop - or in my case staging - branch but from the main or master branch.

I also use this branching stategy for my published extensions, where I sometime support multiple versions of the extension. In that case the main or master branch is still the most recent production ready version, e.g. 2.0. The production ready version 1.5 lies in a sepearate branch called release/1.5. This way I still can make fixes to the 1.5 version, which may support an older still maintained TYPO3 version, while 2.0 only supports the newest TYPO3 version. If you still add new features to older versions you need to start the feature branch from the older version's release branch.