For initial Proof of Concepts, we recommend using one branch to commit, build, and deploy from.

For actual implementation, we recommend having at least 2 branches:

• Main (aka Dev) - for active development work
• Release - for changes that are ready to be released to downstream environments

In addition, some teams create feature branches off of Main and commit all their work to the feature branches.  These teams then use a Pull Request (PR), aka Merge Request (MR) in GitLab, to review the database changes, maybe run a build with tests and code analysis, before merging them into the Main branch.  Anything in Main should be ready to deploy.  Some teams need more control over their releases and therefore having a release branch is valuable because they can control exactly what scripts will be release when.    

There are other teams that have a branch for each environment, e.g.:

• Main
• Test
• UAT
• Staging
• Prod 

If they merged 2 migration scripts from Main into the Test branch and found an issue with 1 of the scripts, they could decide to just push the 1 script to the UAT branch to continue deploying that one change.  Be careful because in this situation deployment to downstream environments may not have flowed through the earlier test environments in the same order as they are deployed to later environments, which could case problems.  Having a Staging environment (or clone) that matches Production as close as possible could help avoid this situation. 

There are many different branching strategies that teams follow.  If you'd like to share what works well for you and your team, please get in touch with the Database DevOps Development Team.

Learn more about:

• Branching strategies through videos on Redgate University
• Dedicated development databases when switching branches