Branching with Gitflow Workflow for SQL Database Projects

By:   |   Comments (2)   |   Related: > DevOps


Problem

As a database developer, how can I understand branching concepts in Gitflow Workflow to be able to work with SQL Database Projects effectively and efficiently in a team?

Solution

The solution is to get a solid understanding of the Gitflow Workflow branching model which supports a very comprehensive development requirements for teams showing willingness to push themselves to the limit.  We will cover a few of these concepts below.

About Gitflow Workflow Branching Model

Gitflow Workflow branching model offers a wide range of professionally proven choices in the form of different branches of your database code to be managed by multiple teams to achieve multiple objectives without losing the focus.

This tip is all about the different branching modes available in Gitflow Workflow provided the database development team responsible behind the database project(s) has a solid background and understanding of distributed source control systems like Git.

Pre-Requisites

Please review the first part of this tip to get familiar with the basics of Gitflow Workflow before we start exploring the interesting and intricate (complex from outside but easy to implement from inside) branching model offered by this workflow.

If you have just landed on this tip but would like to know a little bit more about branching, then I suggest you read through the SQL Database Project Code Branching in Git tip to help you better understand the branching model which we are going to discussed in this tip.

If you are still struggling to understand how two developers can work on the same branch then please visit the Branching in Git with SQL Database Projects tip.

This tip assumes that you are familiar with building SQL Database projects in SQL Server Data Tools (SSDT).

Types of Branches in Gitflow Workflow

A Gitflow Workflow consists of the following branches:

  1. master
  2. dev
  3. feature
  4. release
  5. hotfix
Gitflow Workflow for SQL Database Projects

master branch of the database code

The main and most important branch of code is the master branch which contains the production code.

Please remember the master branch from a SQL Database project context contains the final version of the database project.

In other words, the database project deployment to target environments including Dev (not to be confused with the dev branch), Test and Production is (and should be) entirely based on the master branch.

The master branch should not be allowed to accept direct changes from any of the development team and there must be policies to enforce this standard practice as it should be protected and the only way to update it is through merging the changes via a pull request.

Also, the master branch keeps a full history of the database code changes providing full support to revert to any previous version(s) if required.

Please go through this tip to implement a walkthrough of how the master branch which contains the final version of SQL database project gets updated.

dev branch of the database code

The second most important branch in Gitflow Workflow after the master branch is dev. The database project development (and testing) work is done on this branch of the code.

The dev branch must be created from the master branch in the very beginning of the SQL database project and then all the development team should create local copies of that remote dev branch to start off their work.

This branch, just like the master branch contains database code history but unlike the master branch it is directly accessed by the database development team to save their changes from local to the remote repository.

The dev branch is a must-have (mandatory) branch in Gitflow Workflow and therefore should not be removed at any time unless there is a legitimate reason to do that.

There is no harm in enforcing the policies to protect the dev branch form accidental deletion.

The database code saved on this branch may differ from the master branch because it is like a work-in-progress branch.

When database project changes on the dev branch are ready to be applied to the master branch, it must be through a pull request which serves as an integration request to merge changes with the master branch.

Please refer to this tip to see detailed steps of how to use dev branching with a SQL Database project.

master and dev vs other branches of the code

Please remember the only branches of code which remains during an entire period of the database project development are master and dev while the rest of the branches can be created and removed as per requirements once they serve their purpose.

feature branch of the database code

A feature branch is created by the developer or the development team working on new features of the database solution as per business or technical requirements.

You may be surprised to know that a Gitflow Workflow feature branch is created from dev branch and merged back into the dev branch once the work is complete.

For example a database developer working on a specific feature can create a feature branch from dev such as feature-search-books and another developer can create feature-search-authors from the dev branch and both can work independently on the features they are responsible for to add to the database project. As soon as a feature is complete it can then be merged with the dev branch and the feature such as feature-search-books can be removed.

In other words in Gitflow Workflow a dev branch contains all the completed features added to the project at any time ready to be finally merged with master branch through a pull request.

feature branch in Gitflow Workflow

release branch of the database code

A release branch of the database code contains the new releases while it is entirely up to the development teams and their managers to define the scope and shape of their release.

A release can be anything ready to be deployed just like a feature as it is also created from a dev branch and merged back to dev and master.

For example, a database developer can work on a new release branch created from dev such as release-1-0 and another developer can work on another release branch called release-1-1, but when the work is finished both release-1-0 and release-1-1 need to be pushed to the dev and master (through pull requests, not directly).

release branch in Gitflow Workflow

hotfix branch of the database code

A hotfix branch in Gitflow Workflow has a special purpose and that is to address database production issues. In the database world it is a common scenario when an infrastructure team applies a hotfix to the database system and that hotfix comes from the hotfix branch of the code in the context of Gitflow Workflow.

The hotfix branch is created from the master branch and merged back with both dev and master branches once it is complete.

You can delete a hotfix branch once it serves the purpose.

For example, let us suppose a database developer has been tasked to fix a production issue related to the database project and before he begins his work, he branches off a hotfix (branch) from the master to create a duplicate-data-hotfix branch. Once the developer is done with the work the duplicate-data-hotfix branch is going to be merged with dev and master (through a pull request).

hotfix branch in Gitflow Workflow

Congratulations, you have successfully familiarized yourself with Gitflow Workflow branching model when working with SQL Database projects.

Please stay in touch for the upcoming walkthroughs to see this branching model in action along with some slightly complex database project branching scenarios using Gitflow Workflow.

Next Steps


sql server categories

sql server webinars

subscribe to mssqltips

sql server tutorials

sql server white papers

next tip



About the author
MSSQLTips author Haroon Ashraf Haroon Ashraf's interests are Database-Centric Architectures and his expertise includes development, testing, implementation and migration along with Database Life Cycle Management (DLM).

This author pledges the content of this article is based on professional experience and not AI generated.

View all my tips


Comments For This Article




Thursday, January 28, 2021 - 3:46:22 PM - Haroon Ashraf Back To Top (88123)
Thank you for valued feedback.
It is good to know that you are interested to implement Git workflow in your company/organisation.
Please do not just choose a workflow for the sake of implementation except if it is for learning or testing purposes (such as proof of concept).

In a professional life scenario I would strongly suggest to implement the Git workflow which works in line with your team's working style except if they are super willing to adopt to any new approach.

Having a common dev database is absolutely fine as long as each team member knows how to work on his/her local branch of code.
Please check this tip to see this in action:
https://www.mssqltips.com/sqlservertip/6577/git-branch-with-sql-server-data-tools/

Another way to tackle this is to first start with the basic master dev branch model in Git now it is fine if one developer is working to build a table in his local dev branch while the other developer decides to build a feature consisting of views and procedures in his branch.
https://www.mssqltips.com/sqlservertip/6212/sql-database-project-code-branching-in-git/

Once your team is confident and the (database) features become a lot more different than just building (database) objects then introduce a dedicated feature branching model mentioned in this tip.

Wednesday, January 27, 2021 - 8:07:00 AM - Jochen Back To Top (88105)
I would implement the workflow you discribed in my company, but my problem is, that we have only one dev-database and all our developers are working on this database - develop new features on this dev-database. If we work with feature-branches to develop new Code, we overwrite our code in the dev-database. Another problem is code that developer A from developer B use. What is the right workflow with this situation? Or how can I fix this?














get free sql tips
agree to terms