Master is current production version. Develop is current development version. You branch off develop to work on your feature, then you merge it back to develop

Master is current production version. Develop is current development version. You branch off develop to work on your feature, then you merge it back to develop so you have integration point with your co-workers (you fix conflicts here) which can be deployed to test server or just run through automated tests. When you have develop branch in correct state (whatever that means for your team) then you merge it into master creating new release on production. This way in case of some unforeseen bugs you can fix master which is production like and then merge that fix also into develop so it is present in next release. If you would develop on master you don't have obvious "production like" place. You could do tags, but somehow it fits better with CI setup and Jenkins. In our team we have acceptance branch instead of "release branch". Feature branches are short lived, develop, acceptance, master are long lived branches. You also don't mix stuff because what you really want is one way direction of promoting changes develop->acceptance->master.