What is the master branch and release branch for?

Solution 1:

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 for branches

Solution 2:

As explained in the original post by V.Driessen :

Master is a permanent branch which always reflects a production-ready state. So yes, it is for ready-product which can be downloaded on the market by user.

Release is a temporal supporting branch to support preparation of a new production release. This means mainly bug fixing, documentation, etc as pointed out by minas.

Solution 3:

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.