- https://trunkbaseddevelopment.com/#trunk-based-development-for-smaller-teams
- https://trunkbaseddevelopment.com/committing-straight-to-the-trunk/
- https://trunkbaseddevelopment.com/#scaled-trunk-based-development
- https://trunkbaseddevelopment.com/short-lived-feature-branches/
https://trunkbaseddevelopment.com/branch-for-release/
exception:
- https://trunkbaseddevelopment.com/branch-for-release/#late-creation-of-release-branches
- our maintenance release is an example of this approach
Even if this is strategy that you find useful for the applications you are building, which the original author of the git-flow branching model recommends against, we do not recommend this branching model when releasing artifacts with semantic-release. While the same reflection that recommends against using git-flow for web apps suggests that it may still be a good fit for explicitly versioned software, semantic-release is built with Continuous Deployment/Release in mind instead.
While some have found that the Pre-release workflow enabled by semantic-release can be used to simulate a git-flow-like workflow, it is also worth noting that workflow is not intended for such a use case and requests for support when attempting to use it that way will be closed by our team.
While not specifically a branching strategy,