Git-flow and master with multiple parallel release-branches

Question

We are trying to adopt the successful Git branching model implemented by git-flow. Now, we are working on at least two release-branches, one for the latest stable release an

Answer 1

The master branch should ALWAYS represent your production code base, hence you always merge the code back to master right after a production release.

Tagging is used to "memorize" the exact code which went into a production release so you can go back later and analyze the code if something went wrong.

With this theoretically it shouldn't matter if you tag your code on the release branch or on the master branch after you merged back to master. I personally prefer to tag the code on the release branch as this is exactly the code that went into the build/release (assuming something can go wrong with the merge).

The issue with the development branch concept is that it is single threaded. Brendan in this thread mentioned a strategy which could be used involving a development branch concept.