Install gitflow on Windows Download and install Git from MSysGit or Git SCM. Download and install getopt.exe from the util-linux package into C: Program Files Git bin. (Only getopt.exe, the others util-linux files are not used). The git-flow scripts, however, save you from having to memorize all of this. Installing git-flow. A couple of different forks of git-flow have emerged in recent years. In this chapter, we're using one of the most popular ones: the AVH Edition. Using Tower, you don't have to install anything as the app already includes the git-flow scripts. Git Branch Structure and Policies. We use a branching strategy that we call 'Release Flow'. It's a trunk-based development model, similar to the ones that we recommend to our customers in our branch strategy guide. Release Flow lets us keep master buildable at all times (more on that later) and work from short-lived topic branches.
The people who know me, also know that I'm a huge fan of consoles and CLIs. I run the dotnet CLI as well as the Angular CLI and the create-react CLI. Yeoman is also a tool I like. I own a Mac, but cannot really work with the Mac UI. I really prefer the terminal in Mac. Also Git is used in the console the most time. The only situation where I don't use git in the console, is while resolving merge conflicts. I configured KDiff3 as the merge tool. I don't really need a graphic user interface for all the other tasks to work with Git.
So I do using the Git Flow process.
About Git Flow
In general Git Flow is a branching concept over Git. It is pretty clear and intuitive, but following this concept manually in Git is a bit hard and needs some time. Git Flow is now implemented in many graphical user interfaces like SourceTree. This reduces the overhead.
Git Flow is mainly about merging and branching. It defines two main branches, which are 'master' as the production/release branch and 'develop' as the working branch. The actual work is done in different types of feature branches:
- 'feature' a branch created based on 'develop' to implement new featues
- will be merged back to 'develop'
- branch name pattern: feature/<name|ticket|#123-my-feature>
- 'release' a branch created based on 'develop' to create a new release
- the branch name gets the tag name
- will create a tag
- will be merged to 'master' and 'develop'
- branch name pattern: release/<tag|version|1.2.0>
- 'hotfix' a branch created based on 'master'
- the branch name gets the tag name
- will create a tag
- will merge to 'master' and 'develop'
- branch name pattern: hotfix/<tag|version|1.2.3>
- 'bugfix' less popular. We use 'feature' to create bug fixes
- not available in all tools
- behaves like 'feature'
- 'support' much less popular. We don't use it
- not available in all tools
- almost behaves like hotfixes
I propose to have a look into the Git Flow cheat sheet documentation to see how the branching concept works: http://danielkummer.github.io/git-flow-cheatsheet/
Git Flow is also a tool provided as Git extension. This reduces branching, merging, releasing tagging to just one single command and does all the needed tasks in the background for you. This CLI makes it super easy to follow Git Flow.
Install Git Flow as Git Extension
The installation is a bit annoying, because it needs a some additional tools and some more tasks for just a small Git extension.
To install it you need cygwin, which also is a console that gives you Linux like tools on Windows. The easiest way to install cygwin is to use Chocolatey, which is a packet manager for Windows. (apt-get for windows). You can also install it manually by running the installer, but you need to ensure to also install
cyg-get
, wget
and util-linux
, which is much easier using Chocolatey.To install Chocolatey follow the instructions on https://chocolatey.org.
Open a console and type the following commands
If this is done you can use cyg-get to install the needed extensions for the cygwin console
Open the console and type the following commands:
Now the cygwin is ready to use to install Git Flow. Type
This will open the cygwin bash inside the current console.
Now you are able to run the installation of Git Flow. Copy the following command to the cygwin bash and press enter:
If this is done exit the bash by typing
exit
and close the console by typing exit
. Closing the consoles and open it again ensures all the environment variables needed are available.Open a new console and type
git flow
. You should now see the Git Flow CLI help like this:Every time you checkout or create a new repository you need to run
git flow init
to enable Git Flow.Using this command you will setup Git Flow on an existing repository by configuring the different branch prefixes and specifying the two main branches. I would propose to choose the default prefixes and names:
Working with Git Flow
Using Git Flow is pretty easy using this CLI. Let's assume we need to start working on a feature called 'Implement validation'. We could now write a command like this
This will work as expected:
Since the most of us are using a planning tool like Jira or TFS it would make more sense to use the ticket number here as feature name. In case you use the TFS I would propose to add the work item type to the number:
- Jira: PROJ-101
- TFS: Task-34212
This helps to keep the branch names clean and you don't start messing around with long branch names or wrong names. Git Flow usually deletes the feature branch after merging it back. So the list of branches will never be too long. But anyway, I learned in the past few years, it is much easier to follow ticket numbers than weird named branch names, because we talk about the current tickets every day in the daily scrum meeting.
All the commands that are not related to branches can be done using the regular Git CLI. That means commands to commit, to push and so on.
Git Flow will merge the branches, if you finish them. It doesn't work with rebase or other approaches. This means it'll take over the entire history of the feature branch. Because of this I would also propose to add the ticket number to the commit messages like this: 'PROJ-101: adds validation to the form'. This makes it easy to follow the history in case it is needed.
To finish a feature you should first merge the latest changes of the development branch in:
If you don't add the feature name to the git flow feature finish command, Git Flow will try to close the current feature branch and will write out a message in case the current branch is not a feature branch.
I would propose to always merge the latest changes of develop to the current feature branch to solve possible conflicts within the feature branch instead in the develop branch. This way the merge to develop will almost never have a conflict.
I showed the way how to work with Git Flow using the feature branch. But it'll work the same way with the other branch types. Except with the release and the hotfix branches where you need to set the tag name as feature name. This should be the version number of the release or the version number of the hotfix.
While finishing these two branches Git Flow will ask you for a tag message. After finishing it you need to push both the master and the develop brunch, as well as the tags:
For more information about the Git Flow commands please follow the documentation on Daniel Kummer's Git Flow cheat sheet: http://danielkummer.github.io/git-flow-cheatsheet/. (Which is BTW the best Git Flow documentations ever)
Conclusion
I really love the CLI help of this tool. It is not only descriptive but also explaining. The same way the GIT CLI is explaining things. It is also providing proposals in case a command is miss-spelled.
Git Flow helps me to speed up the branching and merging flows and to follow the Git Flow process. I proposed to use Git Flow in the company and works pretty well there. And I learned a lot about how this process works in production.
As written somewhen in the past, It also helps me to write my blog. I really use Git Flow to organize my posts I'm working on. I'm creating a feature per post and a hotfix in case I need to fix a post or something else on the blog. I use SemVer to version my releases and hotfixes: Every post increases the feature number and a hotfix increases the patch number. The feature number also is the number of post in my blog. The number of open features in my blog is the number of posts I'm working on. This way I can work on many posts separately and I'm able to release the posts separately.
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.
Workflow Model
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.
Note:Theprevious two branches are the starting points for any project. They are very important and should be protected against accidental deletion until the project is better defined. Only authorized leads or project owners should be given the responsibility to merge changes from other branches—such as the feature branch, which we’ll discuss later—to the develop or main 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:
C:Program FilesGit
. - Next, you need to retrieve three files:
exe
from the util-linux package,libintl3.dll
, andlibiconv2.dll
from 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
C:Program FilesGitbin
). - Next, clone or download this repository: https://github.com/nvie/gitflow.
- When done, navigate to the folder named “contrib” (
gitflow-developcontrib
). - Open the command prompt in that directory in administration mode and type this command:
msysgit-install.cmd 'C:Program FilesGit'
.
- Gitflow will be installed and configured in your system and ready to use. You can test it by typing
git flow help
in the command prompt.
Note: In the next discussion, we will use a sample GitHub repository and a Gitflow extension to demonstrate branches in a workflow.
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:
- Switch to the following directory:
- Initialize Gitflow in this repository:
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.
Learn how to set custom branch names when initializing new repositories in GitKraken.
Note: This process has to be done by every developer for any repository they clone in a system. It is not limited to new repositories; it can be used for existing repositories too.
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.
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.
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.
Feature Branch
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:
- 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).
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.
- The following commands publish the feature to the remote repository.
If you check in the remote repository, a branch with the name feature/feature1 will be created.
Note: In the command prompt, the name of the branch you use is
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.
- If you need to delete a branch, you can execute:
git branch -d feature/feature1
Note: If multiple developers are coordinating on a feature, they need to follow the previous steps for cloning, with one caveat: One of the developers has to create and publish a feature branch, which might be empty, so that the others can work collaboratively. If a new developer needs to work, he or she can follow the same process by modifying the following command.
![Git Git](/uploads/1/1/9/6/119612037/667314109.jpg)
git flow feature track feature1
instead ofgit 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. Release Branch
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.
- Commit newly added or modified changes and push to the remote repository.
- Merge changes to the develop branch.
- After a release, merge changes to the main branch.
-or-
Hotfix Branch
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.
- Publish the branch to the remote repository.
- Merge changes to remote repository.
-or-
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.
Install Git Windows 10
![How How](/uploads/1/1/9/6/119612037/759290774.png)
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.
How To Install Git Flow On Windows 10
Gain full visibility into what’s going on under the hood of Git and enhance your Gitflow experience with the most popular Git client on the market.
Stay on the cutting edge of software development by getting innovative tips, trends and stories delivered to your inbox every month!