Software Engineering

Re-designing a Git/development workflow with best practices

I'm looking for some help to optimize and implement best practices on our development framework. Currently, scenario works as following: We have two server/remote branches: main: tested code, ready for production dev01: staging/development branch for quick fixes, complex features, etc. Code flows as following: Dev creates a new development branch from main, develop and test locally, then push it to dev01 branch by creating a local branch of the dev01 branch, integrating his changes by cherry-picking commits from his development branch, remote pushing the new "merged" branch to the server and then creating a PR (that gets Code Reviewed) to integrate it with server's dev01 branch. When the PR gets approved, the CI/CD kicks in to build and deploy on testing environment (web server). QA tests it, and after approving, the same as above to integrate his code in main branch, then it gets-re-tested. After a major version release dev01 branch get deleted and re-created from main. A rough sketch would be something like this: Challenges: We have over 150+ (!) code repositories. Each one of them have a fixed published application for testing (QA) that gets updated when a PR gets approved: main-branch.com/software001 main-branch.com/software002 dev01-branch.com/software001 dev01-branch.com/software002 dev01-branch.com/software... Dev corps isn't segmented into cells/squads. Some repos have a high maintenance rate, so it's not uncommon to have 6+ devs working on code on the same repository, sometimes even on the same pages/modules on the same sprint; Management decided we should have a dev02 branch to isolate bugfixing from complex features before merging changes into the main branch, so the new branch would get another testing environment. Any suggestions on a better way how to tackle this from a managing standpoint (Git branching strategy, etc) ?

May 4, 2025 - 17:13

Re-designing a Git/development workflow with best practices

I'm looking for some help to optimize and implement best practices on our development framework.

Currently, scenario works as following:

We have two server/remote branches:

main: tested code, ready for production
dev01: staging/development branch for quick fixes, complex features, etc.

Code flows as following:

Dev creates a new development branch from main, develop and test locally, then push it to dev01 branch by creating a local branch of the dev01 branch, integrating his changes by cherry-picking commits from his development branch, remote pushing the new "merged" branch to the server and then creating a PR (that gets Code Reviewed) to integrate it with server's dev01 branch. When the PR gets approved, the CI/CD kicks in to build and deploy on testing environment (web server).

QA tests it, and after approving, the same as above to integrate his code in main branch, then it gets-re-tested.

After a major version release dev01 branch get deleted and re-created from main.

A rough sketch would be something like this: flow

Challenges:

We have over 150+ (!) code repositories. Each one of them have a fixed published application for testing (QA) that gets updated when a PR gets approved: main-branch.com/software001 main-branch.com/software002 dev01-branch.com/software001 dev01-branch.com/software002 dev01-branch.com/software...
Dev corps isn't segmented into cells/squads. Some repos have a high maintenance rate, so it's not uncommon to have 6+ devs working on code on the same repository, sometimes even on the same pages/modules on the same sprint;

Management decided we should have a dev02 branch to isolate bugfixing from complex features before merging changes into the main branch, so the new branch would get another testing environment.

Any suggestions on a better way how to tackle this from a managing standpoint (Git branching strategy, etc) ?