The above diagram is one of the best I have found for GitFlow. A video drawing this diagram can be found at DevChild. A tutorial can also be found at Atlassian and far more confusing diagrams can be found everywhere else.

I am not a huge fan of Gitflow as a code management strategy. In fact I have even written a fun rant, but that doesn't mean that it is not important to understand it so that you can decide for yourself what you will use. In order to facilitate this analysis I have listed the pros and cons of GitFlow below.

• It has become a standard - Like it or not Gitflow has become widely used. I am shy to use the word "popular" because most developers I know use it because they have no choice, and complain profusely as soon as you get a couple beers in them. As with any broadly used paradigm it is more likely that someone new you hire will already be familiar with it. However, I believe anyone who is a good developer should be able to quickly understand any reasonably designed branching strategy. In the last couple of years a broad movement has been made in the industry to use a version of Gitflow without the development branch. To be honest, that is no longer Gitflow but if you can keep your boss happy by calling it "Modified Gitflow" and it works better for you, then all the power to you. Here are some references to this trend.
  Gitflow Developer Branch Going Away Gitflow Strategy But Without Develop
• It branches out features for development - Isolating code updates to separate branches, so that teams working on different new features of the application are not stepping on each other toes is a good idea. It is easier to collaborate with a handful of people while making changes rather than possibly hundreds. Of course the more hands you have in a pot, the more likely someone is to make a mistake that blocks other people from working. Branching reduces the number of people in a centralized copy of the code, at the same time, and therefore creates more code stability. Divide and conquer is a concept that works in almost every context.
  
  Branching by feature also allows the business to decide which and how many features will be rolled into a release at a later date, even though the code is being worked on now.
• It branches out releases - Its always a good idea to break out code that is on its way to be released so that it can be subjected to QA and subsequent bug fixes. This stabilizes release code while allowing developers to continue to work on newer features on other branches. You don't want everyone to go idle because you are preparing for release, and you also don't want a bunch of new code dropping into a release that hasn't been tested right before it goes to production.
• Makes the automation of continous integration simpler - The development branch lives for eternity, so continous integration tools like Jenkins and SonarQube can be pointed at this branch. In most other code management strategies, the master is the only branch that is never deleted.

• The Development Branch is a Pseudo Master Branch - A significant amount of time has to be spent keeping these two branches in sync. Imagine this instead. Replace the usage of the development branch with the master. Then instead of merging features directly into this master, they are merged instead into release branches created from the master. These release branches are created when a release is planned and are merged to the master after a release is in production. This is a branching strategy called Candidate Release Branching and accomplishes all the same things as Gitflow in a simpler and more intuitive way.
• Features are combined too early in the development branch - In Gitflow, features are combined before creating the release branch. This mashing together of everything early on makes these features difficult to pull apart again. Keeping in mind that the rigorous QA testing happens in the release branch, so it is not possible to gauge the completeness of a feature before committing to it in the next release. If a small feature is ready to go and is solid and a larger feature is deemed to not be ready, in testing, the two features will be hard to pull apart. Releases start to become "All or nothing".
• Merges to Master are done before releases to production - I see no advantages to this whatsoever. In fact every place I have worked that does "Gitflow" ignores this part of the flow and merges to master after the production release is stable.
• Hot Fixes are a special case - It is a code smell that hotfixes are a special case. Code changes are code changes, and the fact that a completely different braching pattern is done for hotfixes just shows that the entire Gitflow pattern is questionable.