At some point, you need to wrap up the next release, including some of the features you implemented in the last few weeks. To prepare an incoming release you have to branch from develop, assigning the branch a name composed by the release prefix, followed by the numeric form of choice for your release (for example release/1.0).

Pay attention: at this stage, no new feature is allowed! You can no longer merge develop onto the release branch; you can create new branches from that branch only for bug-fixing; the purpose of this intermediate branch is to give the software to beta testers, allowing them to try it and send you feedback and bug tickets.

In case you have fixed some bug onto the release branch, the only thing to remember is to merge them into the develop branch, just to avoid the loss of the bug fix - the release branch will not be merged back to develop.

You can keep this branch alive as long as you want, until you decide the software is both mature and tested sufficiently to go into production: at this point you merge the release branch onto the master branch, making a new release.

After the merge to the master you have a choice: keep the release branch open, if you need to keep different releases alive, otherwise you can delete it. Personally, I always delete the release branch (as Vincent suggests), because I generally do frequent, small, and incremental releases (so I rarely need to fix an already shipped release) and because, as you certainly remember, you can open a brand-new branch from a commit (a tagged one in this case) whenever you want so, at the most, I will open it from that point only when necessary.

This branch is pushed and shared to a common remote repository.