Article updated September 2020
At Syncfusion, we’ve been developing controls and frameworks for software developers since 2001. Over time, as our product line has expanded—emerging from our first grid control to more than 800 different controls across a variety of platforms—our release management process has become increasingly complex. Fortunately, Git came along and made everything easier.
Git is an open source distributed version control system that is flexible and easy to use for all kinds of teams, no matter how big or small. To adopt Git in everyday development, a model called Gitflow was introduced by Vincent Driessen to help simplify development and release management. This article assumes that you have some prior knowledge of Git and its basic terminologies. It aims to further describe Vincent Driessen’s branching model and how his Gitflow extension can be useful in a release management workflow for enterprises.
You can also check out this video, which explains how Gitflow works in GitKraken, a cross-platform Git client.
Gitflow utilizes the core feature of Git, which is the power of branches. In this model, a repository has two core branches:
- Master/Main—This is a highly stable branch that is always production-ready and contains the last release version of source code in production. (For the purposes of this article, we will be referring to this branch as “main”).
- Develop—Derived from the main branch, the development branch serves as a branch for integrating different features planned for an upcoming release. This branch may or may not be as stable as the main branch. It is where developers collaborate and merge feature branches.
Apart from those two primary branches, there are other branches in the workflow:
- Feature—This derives from the develop branch and is used to develop features.
- Release—This also derives from develop branch but is used during releases.
- Hotfix—This derives from the main branch and is used to fix a bug in the production branch that was identified after a release.
We will discuss these branches in detail along with the Gitflow extension used to simplify the management of these branches. The commands we use for the Gitflow extension are based on the Windows environment, but other platforms have similar commands. You can check out the Gitflow wiki for complete details regarding supported commands.
Installing a Gitflow Extension
The following simplified steps will get you up and running on Windows, although GitHub also hosts installation instructions for different platforms.
- Download and install Git for Windows. By default, it will install in this directory:
- Next, you need to retrieve three files:
exefrom the util-linux package,
libiconv2.dllfrom the dependencies packages (libintl and libiconv). (For ease of installation, we gathered and uploaded all these files to http://www.syncfusion.com/downloads/support/directtrac/general/ze/dependencies142480694.zip.)
- Once you have those three files, copy and paste them to the location where Git is installed in your system (i.e. inside a bin folder at
- Next, clone or download this repository: https://github.com/nvie/gitflow.
- When done, navigate to the folder named “contrib” (
- Open the command prompt in that directory in administration mode and type this command:
msysgit-install.cmd "C:\Program Files\Git".
- Gitflow will be installed and configured in your system and ready to use. You can test it by typing
git flow helpin the command prompt.
Setting up Gitflow in Your Repository
When starting a project, you won’t have any code files. No problem, just create a Git repository with an empty directory. When finished, you can clone your repository in your system. In this example, we are using a sample GitHub repository, but the procedure applies for any Git repository.
Increase your knowledge of Git repositories in this beginner Git tutorial video.
- Clone the branch in your system using the Windows command prompt:
git clone https://github.com/bharatdwarkani/gitflow-example.git
- Switch to the following directory:
- Initialize Gitflow in this repository:
git flow init
You will receive a message stating that no branches exist and prompting you to use common branch names. If you don’t want to change the default branch names, press enter to proceed. When finished, you will have a Gitflow extension initialized in your repository.
Main and Develop Branches
The main and develop branches form the base of any repository in Git. The main branch contains a version of the code that is in production, and the develop branch contains a version that is due to be released in an upcoming version. Execute the following commands in the command prompt to check out the main branch in your system.
git checkout main git push -u origin main
You will be prompted for username and password; enter them to proceed. Next, you will need to push the develop branch to a remote repository (i.e. from your system to sync with GitHub). Since the develop branch is only on your local machine, it has to be moved to a remote repository by executing the following commands.
git checkout develop git push origin develop
Better understand the difference between local and remote repositories in this beginner Git tutorial video.
Now you have a repository containing main and develop branches copied from your local machine. This is required only when you first start a project from scratch; otherwise, you could work with one of the following branches.
The feature branch splits from the develop branch and merges back to the develop branch after a feature is complete. The conventional naming of this branch starts with feature/*. This branch is mostly created and used by developers collaborating with teams. The purpose of the feature branch is to develop small modules of a feature in a project.
You might wonder why developers can’t work directly from the develop branch. Why do they need to branch off to a feature branch? To explain this, consider a scenario where you are developing a feature and management decides to drop that feature, as it is no longer required or there is less feasibility of implementing it.
At that time, if you are working in the develop branch directly, it would create a lot of conflicts and possibly break the existing code. Also, to do this you would need to manually delete or comment out code.
Instead, if you branched off a separate feature branch, you could silently discard and delete that branch without affecting the develop branch. Not only does this help develop features, which require the trial-and-error technique, but by using a separate branch you also get an extra level of stability in the develop branch because code from the feature branch undergoes several levels of code reviews and quality assessment before merging into the develop branch.
Pull requests enable code reviews in Git and can be helpful for avoiding mistakes before merging changes. Discover more about using PRs when collaborating with others in this intermediate Git tutorial video:
The lifetime of a feature branch ends once it merges with the develop branch. If multiple developers or teams are working on the same feature, it’s easier for them to collaborate by working on a common feature branch.
The following steps show how a feature branch can be created and published using the Gitflow extension from a Windows command prompt.
- To clone a repository:
git clone https://github.com/bharatdwarkani/gitflow-example.git cd gitflow-example git checkout develop git flow init
- To start a feature branch (the name of the feature branch will be the name of the feature; we are using feature1 in this example).
git flow feature start feature1
After execution, the feature1 branch is created, but it exists only on your system and will not be available in the remote GitHub repository. Now you can continue with your development, adding files and modifying the code. When you’re done with the feature, you can commit it to your local system and later push it to the remote repository.
- Once done, the status of the changes can be checked for newly added or modified files.
git status git add . git commit -am "Your message"
- The following commands publish the feature to the remote repository.
git flow publish feature1 git push
If you check in the remote repository, a branch with the name feature/feature1 will be created.
feature1, but Gitflow adds a naming prefix automatically (
feature/branch) as a convention. When specifying a branch name in Git commands, you need to use the full branch name (
feature/feature1), but in Gitflow commands the general prefix (
feature/) need not be specified.
- Once a feature is complete and the code has been reviewed, you can complete your work in a branch by issuing the command below. Upon execution, the code will be merged to the development branch automatically and the feature branch will be deleted from the remote repository.
git flow finish feature1
- If you need to delete a branch, you can execute:
git branch -d feature/feature1
git flow feature track feature1 instead of
git flow feature start feature1
Apart from this, there is one more branch called
bugfix. It has a workflow similar to the
feature branch, but it is used to fix a bug.
The release branch derives from the develop branch and merges back into the develop and main branches after completion of a release. By convention, the naming of this branch starts with
release/*. This branch is created and used when features are completed and finalized for a versioned release.
Why can’t we directly release from the develop branch? Because the sole purpose of the release branch is to isolate a version of a release that is final but needs some quality assistance and stability from the upcoming version. If we branch off from the release branch, then other developers who are assigned to develop features for an upcoming release and are not involved in the release stability process can continue to development and merge their features into the develop branch without waiting on or affecting the current release process. The release branch helps isolate the development of an upcoming version and the current release.
The release branch’s lifetime ends when a particular version of a project is released. Once this branch merges into the develop and main branches, it can be deleted. And once you have done this, you can tag a main branch with a particular release version—let’s say v1.0—to create a historical milestone.
The following example explains how a release branch can be created and published using the Gitflow extension from the command prompt.
- Start a release branch.
git checkout develop git pull git flow release start release1
- Commit newly added or modified changes and push to the remote repository.
git add . git commit -am "Your message" git flow publish release1 git push
- Merge changes to the develop branch.
git checkout develop git merge release/release1
- After a release, merge changes to the main branch.
git checkout release/release1 git pull git flow release finish release1
git flow release finish -m "Your message" "release1" git checkout main git push --all origin
The hotfix branch is derived from the main branch and merged back after completion to the develop and main branches. By convention, the name of this branch starts with
hotfix/*. This branch is created and used after a particular version of the product is released to provide critical bug fixes for the production version.
The reason we do this is because one problem you might face when branching off from the develop branch is that some of your developers would have already started work for the upcoming release while you are in the middle of the current release. Your release would contain the next version of features, which are not finalized, but you only need to provide bug fixes for the current version. Instead of branching off from develop branch, you can branch off from the main branch, as that branch contains only the current version of the code in production. This way, branching off from the main branch will not affect your production or development version of the product.
The hotfix branch can be deleted once a critical fix for the current production version is released and merged with the main and development branches. Once you have done this, you can again tag the main branch with an iterative subversion of the release; let’s say v1.1.
This example shows how the
hotfix1 branch can be created and published using the Gitflow extension from a command prompt.
- Start a new hotfix branch and commit changes after modifications.
git checkout develop git flow hotfix start hotfix1 git status git add . git commit -am "Your message"
- Publish the branch to the remote repository.
git flow publish hotfix1
Merge changes to remote repository.
git flow hotfix finish hotfix1
git flow hotfix finish -m "Your message" "hotfix1" git status git checkout main git push --all origin
Note: All commands starting with “git flow” are based on the Gitflow extension. Actual Git commands don’t have flow keywords in them. They start only with “git.”
Simplify Gitflow with GitKraken
The Gitflow model helps manage and organize a release better by using Gitflow extensions. Thank you, Vincent Driessen, for proposing Gitflow and for providing an extension that helps simplify the management workflow of enterprise-level releases.
If you choose to fully embrace the tenants of Gitflow order, you can use them with the legendary cross-platform Git GUI, GitKraken, built to help put Git into human terms so developers can code with more confidence.
Mastering the full functionality of Git takes time, so you’ll probably benefit from books like Git Succinctly and GitHub Succinctly. Also consider checking out GitKraken’s comprehensive library of Git tutorial videos, complete with beginner, intermediate, and advanced Git concepts.
Stay on the cutting edge of software development by getting innovative tips, trends and stories delivered to your inbox every month!