Nice article. But things start getting interesting if more than one project is modifying the same code. According to your example, if we have two projects using our library from the master branch, they would use a copy of the code in two release branches, release/fb and release/messenger. In that case, if both make modifications (add new features, correct bugs, …) to their release branches, one cannot say that “the code in production and the code in the master branch are always in sync” when one release branch is merged with the master branch. In this case we need that, everytime the master branch gets updated (that is, the production code), all the projects using this code update their corresponding production code copies with the new master, and the corresponding regression tests are executed. Otherwise, different projects end using different versions of the same code, with different features and bugs. In this case, multiple and independent release branches are terrible.
But there is a corollary: use release branches, one for each project using the code base, but try to concentrate your actual code development (for that code under git, that library/application/…) under one single team. That is, allow for bugs and minor improvements from different projects, but try to restrict the actual, major feature development to one release branch.
Thanks!
