I find strategy 5 particularly interesting, I know google has a single repository for everything but I'm not quite sure to what extent this is. It would be great to read about a breakdown of how this is made possible and how large changes (such as refactoring) are handled.
Just to chime in about strategy 3, we recently adopted it for one of the projects I work on. While I don't have much insight into the others after number 3, I can wholly vouch for strategy 3. The ability to manage projects from both a macro perspective (planned features that affect the product as a whole, irrespective of platform) and from a micro perspective (platform level management of bugs/issues and platform level goals such as A/B testing).
With GitHub's new project interface, we can manage issues as tasks without moving away from a global management and linking solution. One might ask, how is this different from something like JIRA, in-short, it's not. The difference however, is that you never have to leave the place where your code is. Among other things, GitHub provides a cohesive experience that, in my opinion, has been unrivalled of late.
Here is an example of what we have going on.
In the 'master' repository, we have the assets, branding guidelines, documents etc. This solves both the need for version control and also provides a storage tool for our work. The 'issues' feature then provides a means for tracking features, goals and timelines. It also provides a means to have discussion about the features we are trying to implement, we can hash out any points of contention and have a meaningful history about or choices.
We use the issue summary (1) to create an initial proposal, this forms the basis of our discussion. While the labels (2), help us categorize the feature into its various components.
Feedback is simple to add, we can also track what discussions lead to specific product decisions. This is a huge win, we like to talk about data driven development and I'd say this is just as important.
GitHub also tags referenced issues really well. Which means that we can easily hop around to various projects and get insights into what changes, if any, were made.
This strategy works pretty well. I think it helps us become more accountable for our work when we have to check off boxes that indicate to our teammates that we have completed our tasks.
Apologies for the long post, I've become a little passionate about our processes and thought i'd go into a little more detail.
Thanks for the detailed response. You mentioned another benefit of strategy 3. That the master repo could be used for storing documents and other important assets like images. I'm glad people keep discovering new ways of using the tools available for software development :)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.