Branching with Gitflow Workflow for SQL Database Projects
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?
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.
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:
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.
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).
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).
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.
- Please take a look at SQL Database Project with SQL Server Data Tools and GIT and figure out differences and commonalities between Gitflow Workflow and Git Centralized Workflow.
- Please refer to SQL Database Project with Git Feature Branch Workflow and see if you can compare it with the feature branch in Gitflow Workflow.
- Try to design a successful development branching strategy for your team with the help of this tip when your team has to work on a hotfix and a feature at the same time.
About the author
Haroon Ashraf's interests are Database-Centric Architectures and his expertise includes development, testing, implementation and migration along with Database Life Cycle Management (DLM).
View all my tips
Article Last Updated: 2020-12-08