Question: The "*Master branch*" is for a product which is ready and can be downloaded by end-users.

But there are "*release branches*" - I have no ideas who these branches are for. Release for customers? For QA?

[Image showing the branches](http://www.flickr.com/photos/appleboy/5488984404/)

Answer: 
![simplified git workflow](https://i.stack.imgur.com/F00b8.png)

Once `develop` has acquired enough features for a release (or a predetermined release date is approaching), you fork a release branch off of develop. Creating this branch starts the next release cycle, **so no new features can be added after this point**.*Only bug fixes, documentation generation, and other release-oriented tasks should go in this branch(which includes testing also).* Once it's ready to ship, the release gets merged into master and tagged with a version number. In addition, it should be **merged back** into develop, which may have progressed since the release was initiated.

Using a dedicated branch to prepare releases makes it possible for one team to polish the current release while another team continues working on features for the next release. It also creates well-defined phases of development (e.g., it's easy to say, “this week we're preparing for version 4.0” and to actually see it in the structure of the repository).

More info [here](https://www.atlassian.com/git/workflows#!workflow-gitflow) for branches
In the diagram which you linked to, yes, `master` is used for a "ready product" which is released to users. (Not everybody uses `master` this way, though.)

In the diagram, each time the team is preparing a new "ready product" release, they create a new "release" branch. While they are preparing the release, they don't add any new features to the "release" branch -- adding new features could cause new bugs, and they are trying to get the "release" version as stable as possible before it goes public. They do add commits to the "release" branch to fix any problems which are found during final testing, polish up rough spots, etc. So creating the "release" branch marks the "feature freeze" point -- where they decide that only the features they have already developed are going to make it into the next public release.

Once they are ready to go public with a new version of the product, they merge the "release" branch into `master` and tag the commit which is used to build the publicly downloadable product. (If they are releasing version 1.0, they might tag the commit `1.0`, and so on.)

At the same time, as they work on new features, they create new "feature" branches (branching out of `develop`) and commit onto them. When a new feature is working, they merge its branch back into `develop`. `develop` is always moving forward.