The GitFlow Model<\/h2>\n
In 2010, Vincent Driessen proposed a Git model based on branching. It was innovative because it proposed a smooth solution for things like:<\/p>\n
- \n
- Parallel development<\/em>, where many developers can work simultaneously in different tasks using feature branches<\/em> for each one of them. Even the same developer can work in more than one task at a time, which means more than one feature<\/em> branch at a time. When the work is done and passed all the team\u2019s validation phases, it can be merged into the central development branch (the develop<\/em>).<\/li>\n
- Team\u2019s Collaboration<\/em>, by allowing different developers to work at the same time in the same task (so in the same branch). Only commits related to that task are allowed, the developers take turns to validate each other\u2019s commits through Pull Requests<\/em>, and you keep track of changes via commit history.<\/li>\n
- Release Staging Phase<\/em>, when a bulk of features have been finished, they must all be merged into one single branch, your develop<\/em> branch. This is not yet the final production release, but the starting point in which the team decides on the health of all the features and goes for a new releasing process.<\/li>\n
- Emergency Fixes<\/em>. This is also particularly important, the so-called hotfix branches<\/em>. You can create hotfix<\/em> branches from the master<\/em> and urgently change something for production.<\/li>\n<\/ul>\n
GitFlow, however, is not the perfect choice for every scenario. Vincent himself states that it was thought to help with building software that is explicitly versioned, i.e., that needs multiple versions to exist (or coexist) at the same time in the world.<\/p>\n
If you work with web applications (which is basically the highest percentage of developers nowadays), for example, where the deliveries are continuous, where there is no need to roll back nor to keep different versions alive at the same time, then GitFlow is not the best option for you and your team.<\/p>\n
How Does It Really Work?<\/h2>\n
For you to understand the flow better, I\u2019ll make use of the git-flow toolset. It is an auxiliary tool that facilitates the job of working with GitFlow by providing some useful commands.<\/p>\n
To install it, run the following command (on macOS):<\/p>\n
brew install git-flow<\/pre>\n
If you have a Windows, just download<\/a> and install Git SCM. GitFlow commands come with it.<\/p>\n
For Linux users, depending on your version, check this link<\/a> out.<\/p>\n
Don\u2019t worry; this tool won\u2019t mess up anything in your current Git flow. It\u2019s just a helper that creates and deletes branches, etc.<\/p>\n
The first step is to understand the roles of the develop<\/strong> and master<\/strong> branches and how they communicate with the versions of your code. These branches are the most important ones and the key to GitFlow.<\/p>\n
Take a look at the following diagram:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image.png\")
<\/p>\nFigure 1. Simple example of branches flow.<\/strong><\/p>\n
GitFlow works primarily with two main branches:<\/p>\n
- \n
- The master<\/em> branch (in blue) stores all the released features until the date, receives the incoming new features from the develop<\/em> (and only from it), as well as the hotfix changes (you\u2019ll see more in a minute).<\/li>\n
- The develop<\/em> branch (in orange), which has as the only role receiving the changes from the feature<\/em> branches and centralizing them before any further merge. It\u2019s here where the teams usually customize the agile process with steps like validations, code review, definitions of done, etc.<\/li>\n<\/ul>\n
Creating the GitHub Example Repo<\/h2>\n
Start with the creation of a new GitHub repo to hold the workflow example. For this, go to your GitHub account, create a new repo, and fill it with the following options:<\/p>\n
![\"Tela](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/tela-de-computador-com-texto-preto-sobre-fundo-bra.png\")
<\/p>\nFigure 2. Creating a new GitHub repository.<\/strong><\/p>\n
Next, create a new folder on your local computer with the same repository name (st-git-flow<\/em>) and then navigate to the folder via the command line.<\/p>\n
Then, run the following commands, substituting your repository URL:<\/p>\n
echo # Hello World, GitFlow! >> index.md\r\ngit init\r\ngit add .\r\ngit commit -m \"first commit\"\r\ngit remote add origin https:\/\/github.com\/diogosouza\/st-git-flow.git\r\ngit push -u origin master<\/pre>\n
The first command creates a new Markdown file, with a hello world message. You\u2019ll make use of a .md<\/em> file because it\u2019s universal and helpful to track the historical changes. After that, you initialize the Git repo, adding all the files as Git files, and committing.<\/p>\n
The two last commands take care of adding the remote origin and pushing the master<\/em> branch to the remote repo. The remote origin can be seen right after the repo creation in GitHub:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-1.png\")
<\/p>\nFigure 3. Checking out the Git origin value.<\/strong><\/p>\n
Now\u2019s time to run the
git flow init<\/code> command.<\/p>\n$ git flow init <\/pre>\n
When it finishes, this is the output you may see:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-2.png\")
<\/p>\nIt\u2019s a very straightforward command. It creates the master<\/em> and develop<\/em> branches, and asks for the respective names of each feature<\/em>, release<\/em>, hotfix,<\/em> and support<\/em> branches. You can leave them as they are, and press enter until the end except for the version tag prefix.<\/p>\n
(In order to compare Git Flow to Git, I\u2019ll provide the equivalent Git commands throughout the article.) The equivalent Git command to achieve this is:<\/p>\n
git checkout -b develop master<\/pre>\n
Whenever a developer is going to start a new feature, the feature<\/em> branch must be created from the develop<\/em>. This is the branch that hosts the \u201cnext release\u201d development.<\/p>\n
Some team\u2019s Git administrators even block the possibility of generating new branches from the master<\/em> branch for security reasons. However, git-flow doesn\u2019t push the develop<\/em> branch to the remote origin. This is something you must do manually:<\/p>\n
git push -u origin develop<\/pre>\n
The Feature Branches<\/h2>\n
Pay attention to the two new feature<\/em> branches below:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-3.png\")
<\/p>\nFigure 4. Diagram with two new feature<\/em> branches.<\/strong><\/p>\n
There\u2019s no right due date for a task; it can take one day or two months to complete. It\u2019s up to the team to decide the maximum time they\u2019re going to need for any feature.<\/p>\n
Feature #2, for example, was started before #1, and finished first, too. Not just this, it has finished in the middle of task #1. For GitFlow, it doesn\u2019t matter how many features you\u2019re developing at the same time; the flow guarantees that they\u2019ll get to the develop<\/em> and, in the next release, to the master<\/em>.<\/p>\n
If you merge feature #2, for example, and some breaking changes were introduced (i.e., if it adds code that conflicts with the code being developed in feature #1), then feature #1\u2019s merge will fail.<\/p>\n
In this type of situation, which is very common by the way, it\u2019s normal to have the developers talking to each other when merge fixing, to analyze if what one has done is going to break the code of the other.<\/p>\n
Create your first feature<\/em> branch with this command:<\/p>\n
git flow feature start ST-TASK01<\/pre>\n
And this is the result:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-4.png\")
<\/p>\nWithout git-flow, this would be the command to achieve the same:<\/p>\n
git checkout -b feature\/ST-TASK01 develop<\/pre>\n
It\u2019s also a best practice to use tag prefixes in your feature<\/em> branch names, in order to identify them among the others. Some tracking tools, like Confluent Jira, use that information to keep track of the correlated branches of your repositories.<\/p>\n
Since you\u2019re on the branch, you may perform all the needed code changes, and commit them.<\/p>\n
Update the index.md file, for example, to the following:<\/p>\n
# Hello World, GitFlow!\r\n- This is my `task-01` commit.<\/pre>\n
The feature changes are within a new list in which each bullet point contains the respective task id. This way, it\u2019s going to be easier to track the changes history.<\/p>\n
Commit the changes:<\/p>\n
git add .\r\ngit commit -m \"Updating my feature branch st-task01\"<\/pre>\n
Remember, however, that your commits are only local. You must explicitly tell git-flow to publish the branch to the remote origin. For this, you just run the command:<\/p>\n
git flow feature publish ST-TASK01<\/pre>\n
Without git-flow, you\u2019d have to run the following:<\/p>\n
git checkout feature\/ST-TASK01\r\ngit push origin feature\/ST-TASK01<\/pre>\n
Now, your branch is live. You can check it going directly to the GitHub repo:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-5.png\")
<\/p>\nFigure 5. Your GitHub remote branches.<\/strong><\/p>\n
You can even see a GitHub warning at the top of the page stating that a new branch was recently pushed. It also enables the option to create a new pull request, which is not necessary.<\/p>\n
Once you\u2019re done with the feature development, you might merge it to the develop<\/em> branch, or do it via git-flow:<\/p>\n
git flow feature finish ST-TASK01<\/pre>\n
These are the list of actions taken by this command:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-6.png\")
<\/p>\nAnd these are the equivalent vanilla Git commands to achieve the same result:<\/p>\n
git checkout develop\r\ngit merge --no-ff feature\/MYFEATURE\r\ngit branch -d feature\/MYFEATURE<\/pre>\n
The –no-ff<\/em> flag prevents the git merge<\/em> command from performing a fast-forward if Git detects that your HEAD falls short of the commit being merged for security reasons.<\/p>\n
Great, now you have the code merged onto the develop<\/em> branch. This, however, is not remote yet. GitFlow works basically at a local level; all the decisions to send the changes over the remote repositories depend on you.<\/p>\n
Run the command to push things up:<\/p>\n
git push origin --all<\/pre>\n
This command pushes everything that changed locally (branches, tags, etc.) to the remote origin. You\u2019ll make use of it a bit in order to guarantee the git-flow changes are always in sync with the remote.<\/p>\n
You may now go to GitHub and check the develop contents.<\/p>\n
The Release Branches<\/h2>\n
The release<\/em> branch is the branch you\u2019ll create from the develop<\/em> when you and your team are ready to publish a release.<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-7.png\")
<\/p>\nFigure 6. Creating a new release branch.<\/strong><\/p>\n
After a release<\/em> branch is created, no more features can be added to it (and this must be a rigorous policy within your team). Of course, things like bug and hot fixes, docs and urgent changes can be discussed and carefully added. It\u2019s up to the team defining the boundaries.<\/p>\n
When everything\u2019s ready, the branch is merged into the master,<\/em> and a tag is generated. Usually, this process is automated to avoid human errors. The numbering you\u2019re using for the versions also takes place here.<\/p>\n
After that, the develop<\/em> should also receive the release contents, because some important changes (like bug and hot fixes) may be needed by the feature<\/em> branches. Again, automation would be useful here.<\/p>\n
This is an important step of the workflow because many factors can delay the release process, for example, if your company depends on a shipping calendar or the approval of another team. This way, you release (the name speaks for itself) the develop<\/em> branch so the developers may continue to work in the features, while the release code is safe.<\/p>\n
This code creates the first release<\/em> branch:<\/p>\n
git flow release start 0.1.0<\/pre>\n
And here\u2019s the result:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-8.png\")
<\/p>\nWithout git-flow, you\u2019d have to run the following command to create the same release<\/em> branch:<\/p>\n
git checkout -b release\/0.1.0 develop<\/pre>\n
Next, update the Markdown file with the following:<\/p>\n
# Hello World, GitFlow!\r\n- This is my `task-01` commit.\r\n- Our project is going to be released. Version 0.1.0<\/pre>\n
Then, commit the changes:<\/p>\n
git add .\r\ngit commit -m \"Adding release version\"<\/pre>\n
And publish the branch to the remote origin:<\/p>\n
git flow release publish '0.1.0'<\/pre>\n
Here are the equivalent commands for vanilla Git:<\/p>\n
git checkout release\/0.1.0\r\ngit push origin release\/0.1.0<\/pre>\n
This remotely updates the list of branches as well as the warning messages:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-9.png\")
<\/p>\nFigure 7. Remote branches, including the release one.<\/strong><\/p>\n
Finally, release it with the following command:<\/p>\n
git flow release finish '0.1.0'<\/pre>\n
This command does a lot. Without the power of git-flow, you\u2019d have to go through all these Git commands to get to the same result:<\/p>\n
git checkout master\r\ngit merge --no-ff release\/0.1.0\r\ngit tag -a 0.1.0\r\ngit checkout develop\r\ngit merge --no-ff release\/0.1.0\r\ngit branch -d release\/0.1.0<\/pre>\n
The git-flow release<\/em> command prompts a cmd window for you to add a releasing message. Fill it with the following and save it through the shortcut :x! <\/em>+ Enter <\/em>(be aware that you first need to press Esc<\/em> to lose focus on the typing before entering the shortcut).<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-10.png\")
<\/p>\nFigure 8. Leaving a release message.<\/strong><\/p>\n
This would be the output:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-11.png\")
<\/p>\nHere, some interesting things are happening. First, due to git-flow\u2019s local nature, you must push the changes manually to the remote.<\/p>\n
The release<\/em> branch had changes that were merged onto the master<\/em>; git-flow also back-merges the same commits against the develop<\/em> branch. Plus, a new tag was generated: ST0.1.0<\/em>. You must push all these updates through the following command:<\/p>\n
git push origin \u2013-all\r\ngit push origin \u2013-tags<\/pre>\n
This way, when you revisit GitHub, you\u2019d see the following:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-12.png\")
<\/p>\nFigure 9. New tag remotely created.<\/strong><\/p>\n
The tags work as snapshots of your code repo. Whenever you want to consult for a specific spot in time, check the respective tag out.<\/p>\n
Another tip would be about the GitHub commits history. If you enter the develop<\/em> branch, for example, and click in the link with the number of commits above the warning\u2019s box, you can refer to all the changes until now:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-13.png\")
<\/p>\nFigure 10. Develop\u2019s commits history.<\/strong><\/p>\n
Enter each commit, and you may see the change\u2019s diff.<\/p>\n
The Hotfix Branches<\/h2>\n
Every big company can have emergencies and need urgent fixes. With a bunch of people working in the same code while others try to fix a code snippet to ship to production quickly, the whole scenario can get messy.<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-14.png\")
<\/p>\nFigure 11. Creating a new hotfix branch.<\/strong><\/p>\n
Hotfix<\/em> branches come to the rescue by allowing the teams to create a new temporary branch upon the master<\/em>. When done with fixes, you must merge the branch into master<\/em> again, the develop<\/em> branch, and the release<\/em> branch (if there is any).<\/p>\n
That\u2019s why it\u2019s important to always merge a release<\/em> branch into the develop<\/em>, because you can\u2019t track all the changes, especially if you\u2019re working with many and large teams.<\/p>\n
This is the command to create the first hotfix<\/em> branch:<\/p>\n
git flow hotfix start ST-TASK01<\/pre>\n
And here you have the output:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-15.png\")
<\/p>\nThe equivalent non-git-flow command would be:<\/p>\n
git checkout -b hotfix\/ST-TASK01 master<\/pre>\n
Now, change something in the Markdown file:<\/p>\n
# Hello World, GitFlow!\r\n- This is my `task-01` commit.\r\n- Our project is going to be released.\r\n- This is my `hotfix` commit.<\/pre>\n
And, again, commit the changes:<\/p>\n
git add .\r\ngit commit -m \"hotfix changes\"<\/pre>\n
Then, send it to the remote origin by running:<\/p>\n
git flow hotfix publish ST-TASK01<\/pre>\n
Notice that it\u2019s not necessary to inform the full name of a branch. If it is a hotfix<\/em> branch, git-flow understands that by the current command you\u2019re issuing.<\/p>\n
With Git only, you\u2019d need to run the following:<\/p>\n
git checkout hotfix\/ST-TASK01\r\ngit push origin hotfix\/ST-TASK01<\/pre>\n
You may see in GitHub that the new branch was pushed:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-16.png\")
<\/p>\nFigure 12. Published hotfix branch.<\/strong><\/p>\n
Also, since you\u2019ve committed the changes before pushing the branch, these same changes are sent over to the remote origin too — no need for a further push here.<\/p>\n
To finish it, issue the following command:<\/p>\n
git flow hotfix finish 'ST-TASK01'<\/pre>\n
The git-flow\u2019s hotfix<\/em> command is another example of a great shortcut command. It does a lot. These are the Git equivalent commands:<\/p>\n
git checkout master\r\ngit merge --no-ff hotfix\/ST-TASK01\r\ngit tag -a ST-TASK01\r\ngit checkout develop\r\ngit merge --no-ff hotfix\/ST-TASK01\r\ngit branch -d hotfix\/ST-TASK01<\/pre>\n
Once again, you will be prompted to write a message. Write it and finish with the shortcut :x!<\/em> + Enter<\/em>.<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-17.png\")
<\/p>\nFigure 13. Writing a hotfix message.<\/strong><\/p>\n
Again, push the master<\/em>, develop<\/em> and the tags to the remote origin:<\/p>\n
git push origin --all\r\ngit push origin --tags<\/pre>\n
There you can see the new generated tag: STST-TASK01<\/em>. This is how the final index.md<\/em> will look:<\/p>\n
![](\"https:\/\/www.red-gate.com\/simple-talk\/wp-content\/uploads\/2020\/07\/word-image-18.png\")
<\/p>\nFigure 14. index.md final look.<\/strong><\/p>\n
Conclusion<\/h2>\n
You can find the original post which started it all here<\/a>. It has more details over the principles and thinking behind GitFlow. Again, GitFlow is not a religion, nor a panacea. It\u2019s a style, a paradigm. It works well for others; it doesn\u2019t fit the reality of other types of projects.<\/p>\n
There are other workflows too, like the GitHub flow<\/a>, the GitLab flow<\/a>, the One flow<\/a>, among others.<\/p>\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
In this article, Diogo Souza explains GitFlow, a branching model for Git. He demonstrates how to work with GitFlow to create and deploy a feature and a hotfix to GitHub.…<\/p>\n","protected":false},"author":320401,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143521],"tags":[95506],"coauthors":[60461],"class_list":["post-87493","post","type-post","status-publish","format-standard","hentry","category-tools","tag-automate"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87493","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/320401"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=87493"}],"version-history":[{"count":9,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87493\/revisions"}],"predecessor-version":[{"id":87532,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/87493\/revisions\/87532"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=87493"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=87493"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=87493"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=87493"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- The develop<\/em> branch (in orange), which has as the only role receiving the changes from the feature<\/em> branches and centralizing them before any further merge. It\u2019s here where the teams usually customize the agile process with steps like validations, code review, definitions of done, etc.<\/li>\n<\/ul>\n
- Team\u2019s Collaboration<\/em>, by allowing different developers to work at the same time in the same task (so in the same branch). Only commits related to that task are allowed, the developers take turns to validate each other\u2019s commits through Pull Requests<\/em>, and you keep track of changes via commit history.<\/li>\n