# Git - branching strategies for automation **URL:** \ **Category:** Discussions\ **Tags:** cicd, strategy, automation, git, branching\ **Created:** [25 April 2024 20:52 UTC](https://club.ministryoftesting.com/t/git-branching-strategies-for-automation/76086 "2024-04-25T20:52:18Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![danuk](https://avatars.discourse-cdn.com/v4/letter/d/9fc348/32.png) [@danuk](https://club.ministryoftesting.com/u/danuk)\ **Post date:** [25 April 2024 20:52 UTC](https://club.ministryoftesting.com/t/git-branching-strategies-for-automation/76086/1 "2024-04-25T20:52:18Z")
Hi folks we use Git in-house and trying to make our processes a bit more formal and robust, particularly as the number of testers involved in automation on any one project is frequently more than one at a time now… mainly using low-code tools. I don’t see formal names being given to the branching strategies that testers use, but does anyone have an opinion on the merits of, for example, Git Flow vs GitHubFlow? We typically have automation packs that must reflect current production plus a ‘development branch’ (ie a branch that reflects the current state of test environment) and potentially even a UAT environment. Since such projects are typically long-running and very rarely pushed to Production, the release cadence doesn’t seem to fit the principles of GitHubFlow - although this looks far simpler than alternatives. Git Flow appears to be set up for more complex dev projects with many resources. Many thanks Dan --- _[View the full topic](https://club.ministryoftesting.com/t/git-branching-strategies-for-automation/76086)._